C99: Suggestions for style(9)

[Christoph Mallon]

Julian Elischer schrieb:
> Christoph Mallon wrote:
>> variables. Sorting them in a beneficial way for space efficiency is 
>> better left to them (and it is a rather trivial thing to do). Also you 
>> cannot control if more spill slots have to be inserted or some values 
>> do not live in memory at all, so only the compiler can determine, 
>> which order is best.
>> But a compiler can do more: It could coalesce the space of variables 
>> with disjoint life ranges. But this is much harder, because you have 
>> to properly determine the life ranges. Finding an arbitrary 
>> overestimation is easy, but the fun starts when looking at called 
>> functions, which get passed addresses of local variables. Also finding 
>> an optimal coalescence for known life ranges is NP-complete in the 
>> general case. But that's another story. (:
> 
> re-using space or having block-local variables means that when you
> are in the debugger, you can not look at the final value that
> a variable had when you left (unexpectedly) the block.  This can
> be a pain in the neck. (but only a debugging feature)

I'm talking about an optimized build - no matter what the style of the 
original source was, you will have a hard time debugging it.

>>>>>> +Prefer initializing variables right at their declaration.
>>>>
>>>
>>> I have gone the other way on this.  Unless 'const' is being used I 
>>> find I prefer to see them separately initialized.
>>
>> So you like hunting in multiple places instead of having both type and 
>> value conveniently in one place?
> 
> Actually.. yes

So at the one hand you argue that hunting things is bad, but at the same 
time you prefer it? I am confused.

> unconditional initialization is right at the top, AFTER the blank line. 
> Conditional initialization must of course come after the condition, and 
> can not be in the same line as the declaration anyhow.

It is perfectly valid to do so. Warner presented a simple example. You 
just have to limit the scope of the variable, which is a good for other 
reasons, which were explained, too.

>>>>>> +Do not reuse the same variable in a different context, delare a 
>>>>>> new variable.
>>>>
>>>> I buy this largely - though it should be applied with common sense
>>>> as usual.
>>>
>>> hmm. I think an exception might be made for our old friends i,j,k
>>
>> Especially they should be declared right where they are needed. C99 
>> even conveniently allows the iterator variable to be declared in the 
>> first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By 
>> limiting their scope, this prevents accidently re-using stale values 
>> in a different place or other mistakes like the following:
>>     int i, j;
>>     for (i = 0;; ++i) {
>>         for (i = 0;; ++i) {
>>             /* oops, but compiler is happy */
>>         }
>>     }
>>     for (j = 0;; ++j) {
>>         /* more */
>>     }
>> vs.
>>     for (int i = 0;; ++i) {
>>         for (int i = 0;; ++i) {
>>             /* warning about shadowed variable */
>>         }
>>     }
>>     for (int j = 0;; ++j) {
>>         /* more */
>>     }
> 
> while tempting, I can't see that hapenning..
> 
> it stops teh following:
> 
> 
> for (;;) {
>   blah
>   if (foo)
>     break;
> }
> if (i == end_condition) {
>   then we didn't break out;
> }

You reject a common case because of one special case? This is sad. (Also 
there are multiple ways to resolve this nicely, e.g. split the loop into 
a function or invert the condition and restructure the code slightly)

>>>>>> -Use ANSI function declarations unless you explicitly need K&R 
>>>>>> compatibility.
>>>>>> +Use ANSI function declarations.
>>>>
>>>
>>> Everyone shuld be doing that already.
>>> In new code, and in old code that they touch.
>>
>> So, is this pro or contra removing the K&R-clause?
> 
> K&R code should be changed as part of related changes if possible.
> A sweep to change a whole file is probably also ok.
> changing them one at a time is probably not ok.

But this is what actually is practiced.
You still did not answer my question: Do you agree to remove the clause 
so no new old style declarations may be added?

	Christoph