Curly braces
-
The compiler doesn't care. Neither do I.
Well, the compiler doesn't care if you use hungarian notation, but this is how office wars start.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
The only sane format is:
void Afunc()
{
}Why #1: Because half the non-curly scoped languages out there use words or other symbols for marking scope, and BEGIN just doesn't look right at the end of the line! Why #2: Java version 1.1 (the first language I used and learned that trailed the curly brace in books) was so horrible, it gave me one more thing to hate! Why #3: Other than using some automated reformatting that kicks lines to the right or left, I find it very difficult to find missing curly braces in some logic. Matched ones line up very clearly. If they trail the line, when things get a few indents deep, the code becomes hard to read and finding that one line you inserted outside of them takes more time than just begin clear the first time. So, always on its own line!
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
I'd add that a number of us were influenced by K&R C, where you had
int foo(str, y)
char *str;
int y;
{
/* code */
}So an opening curly bracket at the beginning of a function made sense. But then we have:
if(a == b ){
/* code */
}ditto for
while,for, etc. Yes, it is inconsistent between functions and every other compound block of code, but blessed by Kernighan and Ritchie, so who am I to argue. So maybe that's Why #4.Keep Calm and Carry On
-
The only sane format is:
void Afunc()
{
}Why #1: Because half the non-curly scoped languages out there use words or other symbols for marking scope, and BEGIN just doesn't look right at the end of the line! Why #2: Java version 1.1 (the first language I used and learned that trailed the curly brace in books) was so horrible, it gave me one more thing to hate! Why #3: Other than using some automated reformatting that kicks lines to the right or left, I find it very difficult to find missing curly braces in some logic. Matched ones line up very clearly. If they trail the line, when things get a few indents deep, the code becomes hard to read and finding that one line you inserted outside of them takes more time than just begin clear the first time. So, always on its own line!
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
godfetish wrote:
BEGIN just doesn't look right at the end of the line!
I really love 'It just ain't done!' arguments! BEGIN is perfectly fine at the end of the line. In my Pascal days, that was the established standard. Note that Pascal switch statements - CASE value OF - uses the OF keyword to start the case list. I never saw anyone put OF on a separate line. It is matched by an END, just like BEGIN. So why would there be a difference between BEGIN ... END and CASE OF ... END? Or would you write Pascal code as
CASE i
OF
0 : Write('zero');
1 : Write('one');
2 : Write('two');
3,4,5,6,7,8,9,10: Write('?')
END;Note that if you put BEGIN and OF at separate lines, they are still at the end of the line :-)
-
You're not writing for the compiler.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Jacquers wrote:
I generally just use what's in the specific language's style guide.
For C/C++ there is about 42 different bracing / indentation styles fighting for dominance, so referring to "the specific language's" style, as if it was unambiguous, is meaningless. From a logical point, I would prefer
void AFunc() {
}but I have never seen that promoted in any style guide. The opening brace comes when the statement cannot be completed on the current line, indicating that a block is to follow. You should before you leave the line that you won't find a single one-statement line, but a block. I am one who think "if (day==sunday) weekend = true;" in one line is perfectly fine. "if (day==sunday) {" shows that the statement is not complete. The following block is indented. An indentation always follows a brace. No an indentation without an opening brace; no opening brace without an indentation.
"if (day==sunday)
{
}starts the indentation before the brace - that is inconsistent! Undenting follows a closing brace. No undentation without a closing brace, no closing brace without an undentation.
"if (day==sunday)
{
// indented code block
}undents before reaching the closing brace - that is inconsistent. Noone seems to agree with my logic. So I bow my head and follow whatever style guide is enforced upon me. Switch statements mess up indentation in C/C++. One common layout is:
switch (day) {
case (day == saturday):
case (day == sunday):
celebrate();
break;
default:
gotowork();
break;
}The case alternatives are not blocks, so they don't need braces (that is also why they need the 'break'!), but they are indented! I certainly wish they were blocks, for consistency's sake (and I really dislike the 'default is fall through'), so I prefer to make them blocks, adding braces, to justify the indentation. Very few agree with this logic, too - they are so used to seeing indents without any braces justifying it that the inconsistency doesn't bother them.
Why not just put blocks in if you prefer it that way? It also makes it so you can declare variables under the case without the compiler yelling at you.
case 1: {
// do work
}
break; // could be insideTo err is human. Fortune favors the monsters.
-
Are you in this camp
void AFunc(){
}or this one
void AFunc()
{
}I'm in the second
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
First, always. The single "{" hanging in the air - taken to the extreme becomes: if (...) { .. } else { .. } versus if () { .. } else { .. }
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Why not just put blocks in if you prefer it that way? It also makes it so you can declare variables under the case without the compiler yelling at you.
case 1: {
// do work
}
break; // could be insideTo err is human. Fortune favors the monsters.
Yes, like I said. But I do not undent until after the closing brace, so I would indent that as well (and include the break in the block). Why not just do it? Because you sometimes have co-workers. For some time, I was using an embedded language (CHILL) which provided the loop construct FOR EVER DO - infinite loops are not uncommon in embedded software. In a new job, programming IoT in C, in one of the modules I was responsible for, I added a "#define ever ;;" for being able to program "for (ever) {...". After a few months, this was discovered by another programmer (not working on my module), who immediately searched through the entire repository to reveal ever use of such "programming jokes", changing them all to "while (0)", deleting the #define and adding a rude remark on the edit where he requested that all programmers refrain from such unserious coding practices in the future. In the next scrum, he brought up his discovery, reporting to everybody how he had 'cleaned up' my code. I asked if he would accept "while (true)", but no: The proper way to code an infinite loop is "while (0)", with a zero. In classical C, "true" is a #define symbol, not part of the base language, and should not be used for fundamental things such as infinite loops. I got no support from the team at all. Not even for "while (true)". In a code review with the same team, I was asked why I would "clutter up" the code with such unnecessary braces in switch statements. I had the same remarks when I added braces to justify the indentation in one-line conditional statements, like
if (day == sunday) {
relax();
}The coding standard did not allow the "relax()" to be put on the same line as the "if", but mandated the indentation. It didn't explicitly forbid the braces I would like to add - but the programming team did, telling me to remove them. That's how it is working in a team. You have to be obedient. Don't try to make code more readable, or consistent, or safer, if it breaks with the unwritten laws of the team.
-
Yes, like I said. But I do not undent until after the closing brace, so I would indent that as well (and include the break in the block). Why not just do it? Because you sometimes have co-workers. For some time, I was using an embedded language (CHILL) which provided the loop construct FOR EVER DO - infinite loops are not uncommon in embedded software. In a new job, programming IoT in C, in one of the modules I was responsible for, I added a "#define ever ;;" for being able to program "for (ever) {...". After a few months, this was discovered by another programmer (not working on my module), who immediately searched through the entire repository to reveal ever use of such "programming jokes", changing them all to "while (0)", deleting the #define and adding a rude remark on the edit where he requested that all programmers refrain from such unserious coding practices in the future. In the next scrum, he brought up his discovery, reporting to everybody how he had 'cleaned up' my code. I asked if he would accept "while (true)", but no: The proper way to code an infinite loop is "while (0)", with a zero. In classical C, "true" is a #define symbol, not part of the base language, and should not be used for fundamental things such as infinite loops. I got no support from the team at all. Not even for "while (true)". In a code review with the same team, I was asked why I would "clutter up" the code with such unnecessary braces in switch statements. I had the same remarks when I added braces to justify the indentation in one-line conditional statements, like
if (day == sunday) {
relax();
}The coding standard did not allow the "relax()" to be put on the same line as the "if", but mandated the indentation. It didn't explicitly forbid the braces I would like to add - but the programming team did, telling me to remove them. That's how it is working in a team. You have to be obedient. Don't try to make code more readable, or consistent, or safer, if it breaks with the unwritten laws of the team.
I've been spoiled for years by being in a situation where I set the standards and control the direction on account of my experience. That said, I understand where you are coming from, but I don't envy you your coworkers. It sounds like you don't have enough written coding standards. If you all wanted to increase your productivity and reduce problems, you'd have linting and formatting scripts for this if the project is significant enough in size. Or at least that's what I'd do, as it tends to pay for itself in terms of more legible and consistent code, and shorter code reviews. :-D
To err is human. Fortune favors the monsters.
-
Are you in this camp
void AFunc(){
}or this one
void AFunc()
{
}I'm in the second
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
The first style is usually called "K&R", while the second is often named Allman. There are countless variations based on indentation of the following code body. I started out using K&R when I learned 'C' from, er, the K&R. When I learned C# where the convention leans hard toward Allman, I found I preferred Allman braces. I have significant visual problems: myopia, astigmatism, presbyopia, and glaucoma in the left eye, and the right one is made of plastic. Did I mention the cataract forming in the left eye? Allman adds white-space and highlights braces, both of which improve readability greatly for me. One good thing about venerable VS2008 still being an active tool in our shop is that I have a Visual Studio editor macro that converts K&R style to Allman. I don't like the reformatters in later editions of Visual Studio.
Software Zen:
delete this; -
Are you in this camp
void AFunc(){
}or this one
void AFunc()
{
}I'm in the second
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
I generally prefer the latter but it depends ... = [](){ return on my mood + on the number of enclosed statements + on the kind of those statements e.g. for some reason I like lambda 's all in one line + on the complexity of those statements + on whatever surprises the automatic formatting of IDEA has in store for me; }();
-
Are you in this camp
void AFunc(){
}or this one
void AFunc()
{
}I'm in the second
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
This is the only correct way:
void AFunc() {
}Embrace it. Join the dark side. :-\
Jeremy Falcon
-
The first style is usually called "K&R", while the second is often named Allman. There are countless variations based on indentation of the following code body. I started out using K&R when I learned 'C' from, er, the K&R. When I learned C# where the convention leans hard toward Allman, I found I preferred Allman braces. I have significant visual problems: myopia, astigmatism, presbyopia, and glaucoma in the left eye, and the right one is made of plastic. Did I mention the cataract forming in the left eye? Allman adds white-space and highlights braces, both of which improve readability greatly for me. One good thing about venerable VS2008 still being an active tool in our shop is that I have a Visual Studio editor macro that converts K&R style to Allman. I don't like the reformatters in later editions of Visual Studio.
Software Zen:
delete this;I'm totally K&R, but I upvoted this anyway just because you're cool. #no_shame
Jeremy Falcon
-
I'm totally K&R, but I upvoted this anyway just because you're cool. #no_shame
Jeremy Falcon
Thanks Jeremy. Glad to see you coming around here again!
Software Zen:
delete this;
