Keith Devens .com

Note that in your second sample the else is paired with the second if and not with the first if as was intended....

Oh duh, thanks for pointing that out.

For me, where to put the brackets depends on a few things.

First, what did everyone else do? I'f I'm working on someone elses code, I stick with the style they have chosen. It keeps things more clear for the usual maintainers.

Second, what language am I in? If I'm in C#, I go with the VS.NET seperate-line style, even outside of studio. If I'm in perl, I go with the commonly accepted style where it's more compact and start on the line with the statement. Some of that also depends on rule 1, and some of that depends on where the language accepts }; vs. just }

It depends on how much the brackets are going to accomplish. Huge sweeping brackets that take in 50+ lines of code merit their own line for clarity. That said if it's that big a block of code you're going to want to at least have one line of comments explaining it so you can always stick them on the same line. Generally though I stick with the last example.

I don't use curly braces at all if I can get away with an indented one-liner (as is possible with your example). However, if the contents of the braces exceed one line, I always give the braces their own line. I find it much easier to visualize the flow of the code that way. Shoving the braces up against the control structure keywords just looks cluttered and messy to me.

I always use them. In fact, your last sample is almost my style. Using one liner ifs is a bit dangerous and irritating, especially if you want to add more statements (in the if) later.

I'f I'm working on someone elses code, I stick with the style they have chosen.

Of course. Sometimes you're forced to use someone else's style. I'm arguing about what everyone's style should be

Huge sweeping brackets that take in 50+ lines of code merit their own line for clarity. That said if it's that big a block of code you're going to want to at least have one line of comments explaining it...

If I have a big block of code I do one of these things:

I explicitly use a comment block to highlight it, rather than let just a brace stick out.

In fact, your last sample is almost my style.

You probably don't put the space between the if and the parens, right? I don't either -- I just left the example the way it was originally except for the braces.

I like curly braces on separate lines so that I can see various code blocks "line up". I find code squished together much harder to read. Then again, it's just my personal preference. ( I don't worry about an extra line being wasted, since it saved my time when I am rescanning the code later .)

Ditto here on what Jan says. I don't mind the "wasted" space as it allows me to see the structure of the code much more easily. I'm very careful with my horizontal and vertical whitespace.

Anyway, I've got a hi-res screen and small font's set in my editor, so I can afford to waste my vertical whitespace.

That said, I don't mind working with code in the K&R style, like you've almost got yours formatted (except you're using less horizontal whitespace.

Amen. I use the "more conventional".

I checked my copy of K&R earlier and was surprised to find out that K&R style is specifically (p16, 2nd ed):

They always have the brace on its own line in a function declaration, but always have the brace on the same line as its opening block (while, if, do, etc.) inside a function. In addition, they always put a space after the block opener (while, if, etc.) and before its opening brace. However, when defining a function they don't include the space after the function name and before the parameter list (p49):

(They also never use braces for if, for, etc. when not necessary.)

A lot of this seems inconsistent to me. Personally, I prefer:

So, it's consistently no spaces before or after the parameter list or condition, and braces always go on the opening line of the block. I also tend not to use braces if I don't have to. I prefer:

over:

While I'm here:

• A space after every parameter in a parameter list (and in an argument list), same as K&R
• My for loops look like for(n=0; n<c; n++){...}. So, no spaces except between semicolons. Sometimes you get things like for(n=0,l=strlen(str); n<l; n++){...}, and the same thing holds -- no spaces between commas, but spaces between semicolons.
• TABS. I don't know why some people prefer spaces. A tab means precisely "one level of indentation", which is exactly what it's used for in a program. If you use tabs a person can make it look like 2, 4, or 8 spaces if he wants when he edits or views the source, but if you use spaces you dictate exactly how much indentation is given, plus you waste characters and keystrokes.
• Sometimes, if I have a long condition, I'll do something like put each condition on its own line, and put the closing paren on its own line with the opening brace, like so:

I think that's it.

What do you do for comments (in code)?

I'm not sure exactly what kind of response you're looking for. I'll say some things, but I'd appreciate if you could elaborate on your question (what you originally meant) and tell me if I answered it.

1. I always comment at the current level of indentation:

2. If the comment describes the condition, it goes above the while or if (etc.), but if it describes the action, it goes within the block:

3. If the condition or action, as well as the comment, are short enough, I try to save the line and stick the comment on the end:

But that won't always work, and it's better to have the comment take up a line than have it be offscreen and unnoticed. Also, if the block takes lots of lines, and especially if there's deep nesting, I may put a comment after the ending brace to indicate what it's ending. `} //end while` is ok, but `} //end "while you're my bitch"` is better.

4. I try to have a comment to begin every conceptual section of code:

5. If it's a really long block of code, I'll use something like the code block I showed in my earlier comment:

Etc. So, as you can see, they always end in the same place, and are indented according to the current block. I always use exactly 83 `#`s, just because that's about the right size and 83 is my favorite number. If I were choosing a "real" standard to be used by people other than me I'd probably make it 80, especially since that's the standard character screen width. Also, even if the single-line comment indicator is something like ; or //, I'll still use `#`s for the rest of the line because `#` is the most dense character on the keyboard and sticks out the most.

Sometimes I'll do something like `### section description ###` if it's worth more (and should stick out more) than just a single line comment beginning with `#`, but not worth a whole three lines like that. The three line things should be used sparingly, but they should be used to good effect. You can really see them while browsing quickly around code, especially if your editor highlights your comments in green or whatever.

6. If I'm in a language that has some code documentation or commenting standard like:

I'll use that where appropriate.

One thing I forgot in my last comment: I prefer while(1) or while(true) to for(;;), which I don't like.

Did this answer your question? What was it you were originally looking for?

Yeah, I was just wondering how you comment code (which turns out is pretty much how I do it, but I probably use even fewer comments - I think my basic, single-function functions are named descriptively enough that they document themselves).

I've seen code where each function has about half a page of comments in a block with various sections: purpose, outputs, inputs, description, synopsis, etc. Then they usually add all the special characters for phpdoc or whatever documentation system.

I think my basic, single-function functions are named descriptively enough that they document themselves

Yep. The best comments are no comments but simple, self-describing code. The better your code describes itself the fewer comments you have to leave, and the better off you are since A. you don't have comments that can get out of synch with the code, but most importantly, B. when you do comment it'll only be when it's important, so the reader knows to pay attention.

Also, sometimes when I have a really big section of code to cordon off, I'll do something like:

But that's very rare.

Simple.

I can easily scroll up from a closing bracket to the opening bracket. If I mistakenly indented, forgot to close, or what have you - it wont line up.

It gets really beneficial when you have poorly formatted code, and you are attempting to "straighten it out" and add a logic break/loop, and need to ensure the level is correct.

The "extra line" being "wasted" is nothing of the sort - its an investment to ensure easy debugging.

As to why spaces v. tabs? Thats super-easy - In windows, open 2 ssh sessions (putty), copy and paste text from one to the other.

Or open a webcvs page and copy paste from it into a putty session.

Or.. you get the idea.

Tabs get converted to spaces, which borks poor diff - making it hard to copy paste changes and see diff's. With spaces, no such trouble. Plus, all major editors that I know of can do "soft-tabs", automatically placing 4 spaces when you hit tab.

For me, its all about ease of debugging and cross-source coding.

YMMV.

I can easily scroll up from a closing bracket to the opening bracket. If I mistakenly indented, forgot to close, or what have you - it wont line up.

And I can easily scroll up to the nearest thing that's indented less. Or I can use the feature in my editor that brings me to the opening brace from the closing brace. If I mistakenly indented (etc.) it won't line up for me either. I don't see how putting the brace on its own line saves you from anything.

It gets really beneficial when you have poorly formatted code, and you are attempting to "straighten it out" and add a logic break/loop, and need to ensure the level is correct.

Interesting point. When I reformat poorly formatted code I sometimes de-indent everything and then indent blocks from a block's beginning (whenever I come to a while, for, if, etc.) until its closing brace. It seems like the only difference (for this as well as the above) is that you look for a brace while I look for a small constant set of keywords^[1]. Maybe that is mentally more difficult enough to make it worth it to waste a line on the brace. Or maybe it's more worth it in a non-syntax-highlighting editor where all the things that need indentation after them aren't highlighted in bright blue

As to why spaces v. tabs? Thats super-easy - In windows, open 2 ssh sessions (putty), copy and paste text from one to the other.

Wow, that sucks. I tried it and you're right. I don't work with Putty enough to let its bugs dictate my coding habits, but I can see how this could be a problem.

As an aside, I always have my editor display tab and space characters. Frequently I find that people have mixed tab and space formatting without realizing it. Incidentally, the tab character shows up in my editor as a light grey '»', so it makes it super easy to see at a glance what level of indentation I'm at.

Footnotes:
[1]: Though, it just struck me that if you have poorly formatted code (presumably not your own) you'll have to look for those keywords too in order to put the brace on its own line if the code doesn't already use your brace structure.

Saying that readability is improved by lining up braces (brace on it's own line) is a ridiculous argument. I started that way, found it easier to read, then decided it wasn't worth wasting a line on, so I switched. Then found brace at end of line easier. Now, I've worked on so many projects with both, that I find one as easy to read as the other. It's just a matter of what you are used to. Sooo - get with it and stop wasting space or find a decent argument to defend brace on a line (NOT based on readability).

Actually I find the whole idea of using braces to demarce blocks extremely distasteful. The main visual clue to code structure is indentation. With auto-indent editors the norm why add the idea of braces in modern languages? Jeeez! Of course this does raise the issue of tabs vs spaces but you should be using spaces anyway (though that's another debate .