Re: PATCH, RFC: 2.6 Documentation/Codingstyle

["Angelo Dell'Aera" <buffer@antifork.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 Feb 2004 10:48:14 -0500
Valdis.Kletnieks@vt.edu wrote:

>> I think you're really wrong since "deeply nested" means exactly "unreadable 
>> and badly structured" and you could easily realize it by simply spending ~10 
>> hours per day coding and/or taking a look at the code written by someone 
>> which is not you. A simple use of inline functions and a previous thinking 
>> about what you're going to write could easily solve all problems. 

>It might help, but a blind belief that "if I inline things it will all be
>better" won't solve all the problems.  In particular, for the example you
>replied to:

I'm not saying "just inline anything and you'll solve problems". I'm saying
that if your design is well done and you consider the availability of the
inlines your code will surely be better. And maybe you wouldn't need to discuss
why the current limit is 80...

>>>1 tab in the function, 1tab a switch, 1 if, 1 for, 1 if and you have already
>>>lost half of the available space.

>you may very well be advocating the inlining of a 3 or 4 line code segment,
>and moving it to someplace far away in the .c file.  Certainly the compiler
>can probably manage to generate the same code, but now you're condemning
>the next person who reads this code to go flipping back and forth through
>the file to find the only-used-once and unfamiliar function to see what
>this for(;;) loop does.

I prefer going flipping back and forth rather than reading an uncomprehensible 
source. Simpler functions may be analyzed and debugged in a faster way. If
you dislike going back and forth by hand some tools could help you (think 
about cscope). Taking a look at the kernel code it's easy to realize I'm not 
the only one thinking so...

Moreover, if you take a look at the kernel code you'll realize that well 
written code usually defines inlines you really shouldn't need to read since 
their names are quite often self-explaining. Taken from CodingStyle "If you 
have a function that counts the number of active users, you should call that 
"count_active_users()" or similar, you should _not_ call  it "cntusr()"." 

Please don't think simply at those who are reading the code. Think about the 
persons which wrote that code which want to remember what they did two weeks 
before...

>Oh, and it gets very ugly if you have this:
>
>	switch
>		if (foo) {
>			for (ptr=first; ptr->next!=NULL; prt->next) {
>				if (!(ptr->somedata))
>					goto have_to_drop_dead_now;
>				/* more code that deals with ptr-> here */
>
>Creating an inline function for that is going to be.. interesting. :)

You could create a lot of examples where it's difficult to create an
inline.. but they're just examples! There are a lot of ways for writing
the same code and maybe if your example was taken from a real-life code
it could be written in a different and more easy-to-read manner. 

Regards.

- --

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.	  	http://buffer.antifork.org

PGP information in e-mail header


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALP13pONIzxnBXKIRAsddAJ0UkI8RkgyVsCe9CEgCAq3OjT3X6wCfZFOE
b7fPjRZw+/Dfv05H+aO6tpw=
=KXgO
-----END PGP SIGNATURE-----