Reply to thread

Message: [QUOTE="jdallen2000, post: 2399202"] Tend to give the function a name that sounds like a predicate; i.e. isvalid(...) would obviously return true on success; you might use isntvalid() to cope, but often a *successful* function won't want to return zero on success -- it will have a story to tell. I'll believe you, though it saddens me. Pursuing the analogy with English, frequent misspellings eventually make their way into the dictionary, but that doesn't make misspelling right. I hope we're not quibbling over a definition of "standard." The True Style was never universally agreed, of course, but was in very widespread use among the most elite C programmers. Good and bad code may be written in any style of course, but I'm sure there is (was?) a strong positive correlation between coding in True Style and positive traits like clarity and modularity. (I'm not saying True Style is intrinsically conducive to good coding practice, just that those who use it tend to have learned from or emulate the Masters.) Anyway, True Style certainly *was* a standard at Sun Microsystems, a large company founded by one of the greatest Names in Unix history. I'd expected any style mandate to be annoying but quickly became a fan of True Style. Here are my reasons: (1) I was mostly observing this style already, a major exception being brace placement. I was writing } else { but in True Style this is written } else { The second form is simply better than the first! The former form disconnects the keyword "else" from both its antecedent and postcedent and is distracting to read. Also it wastes two lines on the screen compared with the latter form, and this is a "big deal." The left-braces in Non-true code use up considerable vertical space and therefore more scrolling is needed to understand a function. Smaller fonts might alleviate this problem, but that's not an option for those of us with poor eyesight. (Rarely, I may even run statements together on the same line, when the statements are *very* similar, very short, and obviously coupled.) (2) I was proud to emulate the style of so many Masters. (3) As I examined various software I noticed the strong correlation between True Style and good traits like clarity and modularity. True Style became, in my mind, a badge of honor indicating that software deserved to be taken seriously. Linus Torvalds also codes in True Style, so I don't think this is just a Berkeley/Bell-Labs phenomenon. (4) Whitespace arrangement isn't all that important but uniformity would be convenient. Why did all you apostates insist on deviating anyway? :-) * * * * * * * * * * * * * * * * * Although defense counsel continues to recommend `indent' they offered no rebuttal to this point: Are we to conclude that the defendants are satisfied to use only indent-approved spacing? Who's being dogmatic here, anyway? * * * * * * * * * * * * * * * * * 15 months ago, in comp.programming about "bracket convention" I mentioned a stylistic deviation I use, and one of the defense attorneys in the present case then responded: Let me show this code again, my way and in an "approved style." (Some of you may not have processed images or other arrays with multiple homogeneous dimensions, but simple nested for-loops are a very common idiom in such applications.) I'm curious if any newsgrouper actually believes the "approved" coding is more readable here. My way: /* * Do a 3-D convolution. * Convolve in_sig with conv_k producing out_sig. * (Delivered code may be slightly different, for performance.) */ for (x = in_sig->beg_x; x < in_sig->end_x; x++) for (y = in_sig->beg_y; y < in_sig->end_y; y++) for (z = in_sig->beg_z; z < in_sig->end_z; z++) { val = 0; for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++) for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++) for (dz = conv_k->beg_z; dz < conv_k->end_z; dz++) { val += in_sig->dat[x+dx][y+dy][z+dz] * conv_k->dat[dx][dy][dz]; } out_sig->dat[x][y][z] = val; } "Approved" style: for (x = in_sig->beg_x; x < in_sig->end_x; x++) { for (y = in_sig->beg_y; y < in_sig->end_y; y++) { for (z = in_sig->beg_z; z < in_sig->end_z; z++) { val = 0; for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++) { for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++) { for (dz = conv_k->beg_z; dz < conv_k->end_z; dz++) { val += in_sig->dat[x+dx][y+dy][z+dz] * conv_k->dat[dx][dy][dz]; } } } out_sig->dat[x][y][z] = val; } } } I understand that many people, including True Stylists, will deprecate my peculiar for-nesting, especially since the lack of braces or indentation tends to hide the nesting. FWIW, I *never* omit the new-line before a for-body, even if it's the trivial for-body (";"), so (in my private universe) consecutive for's as above will *always* be nested. * * * * * * * * * * * * * * * * * Finally, do let's put the small matter of source code white-space in perspective. I'll cheerfully denounce True Style if the rest of you will denounce the insane politics which have mesmerized a once-great nation. Best wishes for a Truly Stylish and Happy New Year James Dow Allen [/QUOTE]

Verification