Re: [PATCH] CodingStyle fixes for drm_agpsupport

[Jeff Garzik <jgarzik@pobox.com>]

Larry McVoy wrote:
> On Mon, Aug 11, 2003 at 01:15:58PM -0400, Jeff Garzik wrote:
> 
>>>	if (expr) statement;		// OK
>>
>>The test and the statement run together visually, which is it is 
>>preferred to put the statement on the following line.
> 
> 
> Nah.  
> 
> 	if (!p) return (whatever);
> 	if (foo) {
> 		statement;
> 	} else {
> 		statement;
> 		statement;
> 	}
> 	if (!p) return (whatever);
> 
> Perfectly readable.  We have a few hundred thousand lines of code written

Ug.  The first and last 'if' need spreading out away from the big fat 
block, and the "return (whatever)" fools your eyes into thinking they 
are function calls at a 10-nanosecond glance.  Also, having two styles 
of 'if' formatting in your example just screams "inconsistent" to me :)


> like this and I review all of it.  I suspect that I do more reviewing than
> 99% of the people on this list which makes my opinion count more because
> anything that makes my tired eyes absorb the info faster is a good thing.

Absolutely not.  I'm cooler, so my opinion counts more.


> Same for your eyes when you get to my age.  

I bet when you were in school, you had to chip your homework into slate, 
and dinner was brontosaurus-kebob, right?


> I also make people do
> 
> 	if ((a <= B) || (c >= d)) {
> 		xxx
> 	}
> 
> even though I know, if I think about it, what the precedence is.  It doesn't
> matter that I know or you know, what matters is the number of lines of code
> a day you can correctly review.  Anything that helps that means that you 
> are helping people make the source base better.  Try reading 30K lines of 
> diffs at one sitting and tell me again that I'm wrong.  If you do, bump it
> up to 60K lines :)

Absolutely agreed.  I do the same myself out of habit.


>>>	if (!pointer) return (-EINVAL);
>>>
>>>Short, sweet, readable, no worries.  
>>
>>return is not a function ;-)
> 
> 
> See, there is that age thing again.  Think V6.  And it is sort of a function,
> it unravels the stack frame.

hehe :)  I suppose one could say I'm biased towards the compiler view of 
things, 'return' being a compiler intrinsic, controlling code flow like 
several other compiler intrinsics.

	Jeff, who also despises longjmp()