Re: [PATCH] CodingStyle fixes for drm_agpsupport

From: Jeff Garzik
Date: Mon Aug 11 2003 - 13:02:11 EST


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()



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/