Adding comments to this page

When adding a comment, please stick to convention that you add a "signature" after your comment, so people can easily see who's saying what. To add a signature, type --~~~~ (without the enclosing nowiki and code tags for those viewing this as wikitext whilst editing), available as an editing toolbar button with the signature graphic on it when using most graphical browsers. Upon saving your edit, the signature is converted into a static representation of your user name and timestamp with timezone, as the following demonstrates: --Netocrat 13:20, 24 January 2006 (GMT)

This page was seeded as a summary of the style discussion within the comp.lang.c subthread, c.l.c wiki update, and referenced posts are within that thread.

Preliminary Decision

Since there's been no comment/discussion for a month or so, I've updated the article page to reflect the K&R style suggestion, along with the suggested minimalist guidelines, and I've have started trying to make sure that new code conforms. We can add general (not strictly enforced) guidelines as they crop up - the first that I've added is a single-exit guideline. --Netocrat 15:06, 14 March 2006 (GMT)

Suggestion of K&R

My opening post suggested K&R style as the one most likely to generate consensus. --Netocrat 13:20, 24 January 2006 (GMT)

Most objective basis for choice

In later posts I disclosed a personal preference for K&R style and explained that the reason I believe it's most appropriate is that it was developed by the founders of the language, and this is the most objective basis I can see for choosing a shared style for a public repository - for C in particular given the general respect for the discriminatory abilities of its designers. --Netocrat 13:20, 24 January 2006 (GMT)

Possibility of other objective measures

In the post referenced above I also indicated that a more objective basis for choosing a style than "developed alongside the language and by its founders" may be possible - e.g. if someone were to present a set of well-conducted studies and metrics to show that another style was in general better, for some reasonable definition of "better" - but that I'm not aware of such a basis. --Netocrat 13:20, 24 January 2006 (GMT)

Unlikely

Richard Heathfield's response was that the likelihood of universal acceptance of K&R or any other style is zero.

No-brainer for indentation

Part of Steve Summit's response was that considering style from the perspective of indentation and bracing alone, there's no question that K&R is the only candidate for a common Wiki style if it's decided one is necessary.

Suggestion of Indian Hill

pete's post advocated Indian Hill style.

Suggestion of minimalist guidelines

Michael Wojcik's post reasoned that a lack of guidelines is preferable to too many guidelines; guidelines are often counterproductive, leading to a tiresome and sometimes awkward consistency for no sake but its own. It's preferable to leave the style guidelines at "consistent", with some additional guidelines such as:

• keep line length moderate
• avoid //-style comments
• avoid tabs or at least avoid mixing them with spaces for indentation

Statements of indifference

Several people have indicated in their responses that they're indifferent to which choice is made; this includes a Flash Gordon post, a Default User post and a Randy Howard post.

The open question of indentation style

Steve Summit's post as referenced above defined an open question as: should a large, consistent, multi-author, public document such as a c.l.c. Wiki display all its code samples using a single, consistent indentation style?

The use of automated indent

A Randy Howard post and the Flash Gordon post referenced above suggested that the need for choice be obviated through use of a tool such as GNU indent.

Note that I only suggested it for display, with user configurability, not that code be reformatted on submit. --Flash Gordon 14:34, 24 January 2006 (GMT)

Loss of information

I responded that on-the-fly conversion using an indent tool would be fine as an option but that it could also remove deliberately encoded information, so conversion shouldn't be the default. --Netocrat 13:20, 24 January 2006 (GMT)

Beyond bracing and indentation

Steve Summit's post as referenced above also suggested that there's more to style than where the curly braces go; more important things include:

• that variable names make sense
• that expressions clearly show what they're computing
• that control flow isn't tangled
• that functions are well-modularized

Good for Steve. Blowed if you'll get me to write K&R - it's about as intuitive as underwater unicycling. --Rjh 16:16, 14 March 2006 (GMT)

(I think you've taken this out of context - what Steve Summit wrote in that part of his post was orthogonal to whether K&R or any other particular brace/indentation/layout/whitespace-base for a style was chosen. Your comment's otherwise valid of course.) What style guidelines for the wiki would you suggest then? --Netocrat 16:53, 14 March 2006 (GMT)

Well, that's the problem - you'll never, ever, ever get everybody to agree to the same style. Some clc people are rabid goto merchants, and others are structuralists to the core. Some are adamant that K&R is some kind of religious observance, and others think it's Just Stupid (TM). I don't see that you're ever going to get any kind of consensus. --Rjh 01:51, 15 March 2006 (GMT)

That may or may not be true, but I'd far prefer for you to point out a solution than a problem. Several solutions have been expressed above; the only two I consider truly workable are the K&R suggestion and Michael Wojcik's minimalist suggestion (essentially "no guidelines" bar two or three simple rules). IMO it's preferable to have reasonable consistency across the wiki, which is why, after leaving a period for further discussion (and believing that no one else would if I didn't), I finally put up K&R on the guidelines page. So then, is Michael Wojcik's suggestion preferable to you, and if not, what will you accept (ignoring the need for consensus when answering the second part of this question)? --Netocrat 04:30, 15 March 2006 (GMT)

i+1 has no spaces, right?

Just for explicitness's sake, I thought I should mention that, contrary to the statement that "all binary operators should have spaces preceding and following them", constructs like "s[i+1]" or "x >> (p+1+n)" should not have spaces around the pluses. "s[i + 1]" just looks wrong. I haven't seen this explicitly mentioned anywhere, but it is what is done in K&R (e.g. p. 49) -- JesseW 20:34, 10 July 2007 (BST)