[geeks] Web Browsers that Don't Suck
Jonathan C. Patschke
jp at celestrion.net
Fri Apr 12 16:58:39 CDT 2002
On Fri, 12 Apr 2002, Joshua D Boyd wrote:
> And 132x24 is cheating. Those functions are supposed to be 80 columns wide,
Yes, always. You never know when you might want to print a hardcopy of
the code, and then go debug it under a tree the old fashioned way: with a
pencil and scratchpad.
> no more. Occasional 36 and rare 48 line functions are to be allow. Using
> line saving tactics like:
> if (x<0.0) x=0;
> or
> for (int i=0; i<10; i++) c[i]*=a[i]*b;
> are encouraged.
>
> At least that is my view.
I'm going to disagree, purely stylistically. I always brace and indent
clauses like that, since it makes adding conditional debug code so much
easier later:
if (x < 0.0) {
DEBUG_PRINT("Whoa; x is negative. Is this a bug?");
x = 0.0;
};
...
for (i = 0 ; i < 10 ; i++) {
c[i] *= a[i] * b;
ASSERT(c[i] <= THEORETICAL_MAXIMUM);
};
And, yes, I really do use two-space indents[1], rather than a full tab
stop. It pisses some people off, but I don't think it makes the code
noticably harder to read. Then again, long functions don't bother me,
either, if they're sensibly long. Long functions only bother me if they
could be made -much- shorter by using a helper function, but then it's
probably already violating the rule of "no repeated code" and should be
tossed-out and rewritten.
--Jonathan
[1] For C code, anyway, shell-code gets a full stop because shell-code
rarely nests as deeply.
More information about the geeks
mailing list