[Openmcl-devel] CCL kernel coding style question

[Pascal J. Bourguignon]

Ron Garret <ron at flownet.com> writes:

> The CCL kernel C code is written in this style
>
> return_type
> function_name(args…)
> {
>   code…
>
> Instead of what has always seemed to me to be the much more readable
> (and conservative of screen real estate):
>
> return_type function_name(args) {
>   code…
>
> Because I hold the CCL developers in the highest regard I thought I
> would ask: is there a reason you chose the first style over the
> second?

Obviously you've never programmed in Pascal.

C is a loony and twisted language.
Who puts the type first and the variable second?

The place of the return type of a function obviously is AFTER the
function signature.

The consequence of putting types and modifiers first, is that their size
having a high variance, the function names and parameters cannot easily
be aligned anymore.

    export t1 foo(…);
    export ttttttyyyyyyppppppeeeeee22222 bar(…);

or:

    export t1                            foo(…);
    export ttttttyyyyyyppppppeeeeee22222 bar(…);

both are ugly.


Instead, in a sane programming language:

    function foo(…):t1;
    function bar(…):ttttttyyyyyyppppppeeeeee22222;

things are nicely aligned.


So one way to recover some sanity in C, to the cost of having to ignore
every other line, is to put the return type on its own line.


    export t1
    foo(…);
    export ttttttyyyyyyppppppeeeeee22222
    bar(…);

(You may use grep -v export).


An alternative is to align this way:

    export t1                            foo(…);
    export ttttttyyyyyyppppppeeeeee22222 bar(…);

but when you start doing it for parameter types too, it gives lines that
are really too wide.  And it's difficult to be consistent in all
sections of code.

Another alternative that I used when I still programmed in C was to use
macros:

    PROCEDURE(foo,(…),t1)
    PROCEDURE(bar,(…),ttttttyyyyyyppppppeeeeee22222)

and with different definitions of the macro in header and in source
files, to paper over the required syntactic differences.  But the
problem with C macros is that they're not taken into account by editors
and IDEs, and few C programmer use them (I notice heavy use of C macros
only in lisp implementation sources written by lispers).


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk