>
>> variables
>> =========
>> declaration of pointer, * is adjacent to variable not type (as it's
>> part of the variable not the type, avoids int* i, j; etc.)
>
> This is a very smart point. I see this very often, even though not
> in sbase. a grouped declaration "int* a, b, c;" could falsly
> indicate, that b and c are pointers, too, which is not the case.
Another reason is that adjacent to the type breaks the rule "declare
it as use it".
>> variadic macros
>> ===============
>> yay or nay?
>
> Why not? :P
>
>> functions
>> =========
>> declarations at top of file
>> declarations, definitions, in alphabetical order (except main, at end of
>> file)
>
> No, I prefer declarations in order. This keeps everything in a logical
> context.
Totally agree, it also removes prototypes needing (duplication is not good ever,
so if you can avoid it then do it).
>> line length
>> ===========
>> we aren't limited to 80 columns in our terminals anymore, no need to
>> pretend we are
>> if using more columns makes code more readable, do so
>> it also means we can fit more code on a single screen, less scrolling
>> (some hard limit so we don't have 300 character lines?)
>
> Should be debatable. It's like with LaTeX, where you think at first why it
> puts your text into such thin columns by default, but as soon as you hold
> the book in your hand you realize why.
> The natural reading-buffer in your brain is only so big. I'd really like to
> test out how strictly following the 80 columns rule might work out.
> What you need is a good rule-set on how to format multiline if-blocks and
> other
> things.
Yes, there is also other reason. If you code goes longer of 80 columns you
usually are doing something wrong and you can write in another way
(with less indentation levels for example). Of course, there are some cases
where this rule must be broken (printable strings).
>> do use compound assignment and test (e.g. if (!(p =
>> malloc(sizeof(Type)))) ...; )
>> unless you can assign at declaration (e.g. Type *p =
>> malloc(sizeof(Type)); if (!p) ...; )
>> (although that's more rare without mixed code and declarations, discuss)
>
Or if line is too much long. Then it is better to split it in assignation
and test.
>> early returns/exits
>> ===================
>> if needed use label + goto for cleanup instead of multiple nested
>> levels, however this can normally be avoided (discuss)
>> return/exit/fail early instead of using multiple levels of tests
>> do not clean up on fatal errors (just enprintf())
>> do not use an else/break/etc. after returning/failing
>
> I have no problem with goto. It often simplifies things dramatically
> and there's no reason to regulate it or punish its use.
"If you want to go somewhere, goto is the best way to get there."
Ken Thompson.
Regards,
