C99: Suggestions for style(9)

[Julian Elischer]

Christoph Mallon wrote:
> M. Warner Losh schrieb:
>> In message: <20090430233648.GA95360 at keira.kiwi-computer.com>
>>             "Rick C. Petty" <rick-freebsd2008 at kiwi-computer.com> writes:
>> : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
>> : > : > This is the biggest one, and I think it may be too soon.  
>> Also, we
>> : > need to be careful on the initialization side of things because we
>> : > currently have a lot of code that looks like:
>> : > : > : >     struct foo *fp;
>> : >     struct bar *bp;
>> : > : >     fp = get_foo();
>> : >     if (!fp) return;
>> : >     bp = fp->bp;
>> : > : > this can't easily be translated to the more natural:
>> : > : >     struct foo *fp = get_foo();
>> : >     struct bar *bp = fp->bp;
>> : > : > since really you'd want to write:
>> : > : >     struct foo *fp = get_foo();
>> : >     if (!fp) return;
>> : >     struct bar *bp = fp->bp;
>> : > : > which isn't legal in 'C'.
>> : : I thought we were talking about C99, in which case this is 
>> perfectly legal.
>> : I certainly use it all the time in my C99 code.
>>
>> Hmmm, looks like that was added.  That's ugly as C++...
> 
> I do not think, this is ugly. On the contrary, it aids maintainability, 
> because it reduces the scope of variables. Also quite some variables are 
> only initialised and not changed afterwards, so it's nice to have the 
> declaration and the only assignment in a single place. IMO this is a 
> quite natural style, because you don't have anything in the code, before 
> it is needed: Get the first pointer; if something is wrong, bail out; 
> get the second pointer - the second pointer does not (textually) exist 
> before it is needed.
> 
>> : And I thought this was the point of this discussion, to be able to 
>> declare
>> : variables when you first use them.
>>
>> That's one of the proposed changes, which I think is a mistake and
>> would cause the most code churn.  And it isn't one of the items that's
>> being discussed: only moving variables into inner scopes is on the
>> table...
> 
> No, this is not what I intended. The idea is to limit the scope of local 
> variables as much as is sensible. Maybe I should have been more 
> explicit. On the other hand, I also did not mention that it is just 
> about moving to the start of inner block statements.

I can see moving declarations to an inner scope {} in some cases but
I think allowing us to declare them mixed in with the code,
(even though some compilers allow it) will be a mistake.

I think this was done to allow macros to declare vars they needed.
I'd hate to see it in our code..



> 
>     Christoph
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"