Thread: Curly Brace Placement

I have a feeling that MK27 is trying to be funny, but since there was no reply to my PM, I shall assume the worst

Originally Posted by MK27

I am sure there is a whole pack of cowards here who totally empathize with the obvious (and elegant) logic of my indentation style and have even done similar things themselves, when allowed, but are afraid to speak up because it is too late -- history has spoken*.

The reason why I find the MK27 style not reasonable for reading is that I do not find it effective for determining scope. I consider the delineation of scope to be one of the purposes of indentation.

If the statements "fit tidily on one line", I do not really have much of an objection to placing multiple expression statements on a single line, since I do not think that it harms readability (whether vertically or horizontally, the reader will still read statements sequentially). This is especially true if the entire line is a block of scope by itself, e.g., the definition of a function.

The problem I have is with the placement of multiple statement conditions on the same line, and the placement of multiple closing braces on the same line. I feel that these make it more difficult to get a mental model of the scopes involved, and a rough idea of the flow of control, at a glance. Additionally, it may also make it more difficult to use the code folding feature that is present in some editors.

Originally Posted by laserlight

Additionally, it may also make it more difficult to use the code folding feature that is present in some editors.

Then these features need to be fixed Also, I think:

Code:

}  }  }

Might serve as some kind of clue about scope. This is only useful where the first two or three opening braces can fit one one or two 140 character lines, of course. Part of my problem is I use a "proper" 8 space tab, so if I can cut one level of indentation out that way (without lining up one block in another, cause the all the outer block contains is the inner block), then that's great. Such nested blocks (ie, where only the last {} contains code) are common enough to merit an exception.

Generally, I do not write this way, I compress vertically afterward as I think there is a difference between reading code while you are working on it (want lots of whitespace) and reading thru it later (easier with less whitespace, IMO). But I tend to read things like a book, eg, mostly left to right and then top to bottom, as opposed to mostly top to bottom and then sometimes left to right, which would be "allmanesque").

Normally I just use:

Code:

{
    c;
    b;
    a;
} if( cond );

Originally Posted by MK27

Then these features need to be fixed

Of course, if you can convince more people, especially those that maintain code editing software, that MK27 style is actually reasonable. Nonetheless, my observation about the current state of this technology remains.

Originally Posted by MK27

Generally, I do not write this way, I compress vertically afterward as I think there is a difference between reading code while you are working on it (want lots of whitespace) and reading thru it later (easier with less whitespace, IMO).

That is interesting. I find it easier to write with less whitespace, but I tend to write with more whitespace because I find it easier to read with more whitespace.

Heh. Braces. "dead horse topic" indeed. And quite absurd to make it a single-poll choice. Let's see ...

I use a modified K&R for my personal projects. Classes, functions, namespaces, and switch get next-line braces. All others get same-line braces, unless the condition is broken, in which case they get next-line braces. Anyway, four spaces for indentation. Broken lines line up "prettily" with the previous line, on a case-by-case basis.
Except when I'm coding in Java. There functions often have same-line braces too. One tab for indentation (set to 4 chars). Broken lines are indented once.

I use strict Allman at work, because otherwise you have to fight VS, and that's never fun. One tab for indentation.

Clang uses same-line braces exclusively, so that's what I'm doing there. Two spaces for indentation, broken lines are aligned "prettily".

Boost uses something very similar to my personal style, but with a stronger tendency towards same-line braces.

In general, I do whatever the existing source does.


As for reading, I don't give a damn. Bracing does not matter. Unless you use something completely insane, you never need more than a few minutes to adapt to a new style. Reading code is all about logical code structuring and good variable names.

How can I possibly vote for one option?

I myself dont know why I use style 2, may be because I use it from the beginning.

Originally Posted by idelovski

I realised I don't folow official style at all

The style is only "official" if it is mandated by the coding standard that you are required to follow. It just so happens that some styles have historical significance and thus have been assigned names. Except for the use of two spaces, the style that you follow is also in common use, from what I have seen.

Originally Posted by laserlight

It just so happens that some styles have historical significance and thus have been assigned names.

Well, that's what I actually meant by official. I should have used quotes maybe.

But now I realize there's some good to this following of formatting styles. When I find some useful piece of code on the internet, I always reformat original style and parse it in my head at the same time. This way I can understand it much better/faster if there's a lot I need to change in it.

baah! Whitespace is for wussies!
( Hope the word 'wussie' isn't inappropriate to the PG-13 rating thingy D: )

Originally Posted by Akkernight

baah! Whitespace is for wussies!
( Hope the word 'wussie' isn't inappropriate to the PG-13 rating thingy D: )

inb4b&

Originally Posted by whiteflags

I thought there was a reason I felt a little sick yesterday. I threw up a little in my mouth, too.

Ha! Jealous! That last one was actually a joke, but here's something for you to really drool over:

Code:

for (i=0;i<hslen;i++) { if (((UC==0) && (tolower(haystack[i])==copy[0])) || ((UC==1) && haystack[i]==copy[0])) {
        for (ii=1;ii<nlen;ii++) { if (((UC==0) && (tolower(haystack[i+ii])!=copy[ii])) || ((UC==1) && haystack[i+ii]!=copy[ii])) 
                        break;
        else if (ii==nlen-1) return i; 
}       }       }

Notice I threw in the extra (8 character) tab* for "break"? Now that's inspiration in the style.

* or "eightball" as we like to call it

Code:

int function(void) {
if (blah) {
    code;
    }
else {
    more code;
    }
}

I acquired that style from having a compiler I used to use output the level (block depth) along side the source code. It told me the block isn't entered until AFTER the opening brace, and is not exited until AFTER the closing brace. I indented accordingly.

I then wrote a little tool to scan the source file and compare with the block level shown... it pointed out any indentation inconsistencies and found the first occurrence where braces were not in synch with what was intended. Very useful - compared with a compiler which would only tell you there was an error at the very bottom of the listing. Waayyyy too late. This was 25 years ago. Today's Microsoft compilers still can't do that!

The exception is the entering of a function... why waste valuable available width? I start off at the left edge.

I don't think the brace deserves its own line... so I place the opening brace on the end of a real line. Unless I anticipate adding more code to a block I also place the closing brace on the end of a real line.

So more often it looks like this:

Code:

int function(void) {
if (blah) {
    code;
    code; }
else {
    more code;
    more code; }
}