On Fri, Dec 22, 2006 at 11:44:02PM +0100 I heard the voice of Rhialto, and lo! it spake thus: > > Once we settle on some layout, [...]
Which we should move toward. The present situation is downright painful. The style is inconsistent in every way. The amount of cruft is staggering; what variables we declare where and in what scope, what functions are prototypes where (or at all)... And lord, the indentation. Some places use a tab for each level. Some use the alternating 4 spaces/tab abomination. Some places even use 2 spaces with replaced tabs, and then compound the offense by using tabs for alignment; e.g., m4twmFileInput(); 4 spaces in to the body, then 2 spaces per indent level, replaced out by tabs every 8 spaces. There are places where it's obvious somebody had a 4-char tabstop and indented a tab in to match 4 spaces in surrounding code. And then there are the obvious bugs, not even intentional nuttiness; see ChangeOccupation() where there are a lot of tabs preceeded by 1 space. Bleech! The following, I think, should not be contentious: - Tabs should not be used for alignment. See e.g. #define's and comments after lines in structure definitions in twm.h and other .h's. This goes all wonky with any tabstop except that of the person writing it. The only thing a tab is the same size as is a tab, so unless they happen at the beginning of the line in equal numbers, you can be assured that tabs will misalign somewhere. - Single-line if()'s are the devil. I've used 'em in code before, but almost always for bad reasons. Similarly, cramming two statements on one line like "i = 0; j = 0;" is usually more hinderance than help. - We have way too many lines that are way too long. Sub-80 char! Going with that, comments at EOL are probably usually best put elsewhere. - Speaking of comments, we need a lot more of 'em. Except in the places where there are long comments embedded in the middle of statements, like in the if() a dozen lines into ChangeOccupation(). I'm hot on comments and vertical whitespace. - We have too damn many global variables. These are probably more so: - Indent with either 1 tab per level, or some number (2? 4? 3 maybe, to really mess with people mixing in tabs?) of spaces per level. No number of spaces should ever turn into a tab (see ci and pi flags in vim). That part at least shouldn't be too argumentative; it's which of the two that gets rough. - Spaces before args. "if (x)" and "foofunc (x)". I don't like 'em. - Braces. It seems like a majority (but not a large one) of the code K&R's it. I prefer Allman; I especially dislike the cuddled up "else if"'s you end up with in K&R... Other random bits: - Multi-line alignment. I tend to align later lines where they 'belong' logically; up to the ( of function calls, and sometimes layers deeper on long many-parenthesized if()'s, except when that is "too far" over (where "too far" is interpreted on a variety of criteria), in which case I push them over 2 indentation levels (which distinguishes them well from inner blocks). - Underscores good. CamelCase bad. - Defining functions with a newline before the function name sure does make finding stuff easier. void foobar(blah) not void foobar(blah) - Implicit comparisons as boolean (e.g., "if(x)" instead of "if(x!=NULL)" and equivalents for numerics) bad. - I don't like multi-line comments that start on their first line... - Urg, there are array references with spaces before the [ too. And some function calls with MANY spaces before the (; see workmgr.c around line 1700. - We should probably have less commented out code. Unless it's clarifying something, or commented out rather short term... well, we've got a VCS after all. That's what it's for. And other stuff that I've managed to put out of mind, probably. We should hash out the One True Ctwm Style and be done with it, so we can use it for new code and convert existing code as we're messing with it. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
