I always use the new line method, as for me its much more clear. But whenever I come across someones code and if they have done it the same way I wont change it, unless I am rewriting their code & then I will.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Do you put the curly brace on the same or new line?
- Thread starter kainjow
- Start date
- Sort by reaction score
+1 ; for understanding the value of readability.
FFS, are people STILL using K&R formatting by choice?! Lessened readability is never worth squeezing a few more lines of text on the screen. Putting opening braces on the same line as the conditional is a monstrosity that only existed because of 2 reasons:
1) Terminals only had 24 lines of text.
2) Hardcopy programming books had limited space on a page, and it was more efficient to "scrunch" the code up, even if it was less readable.
If you have been brainwashed by the Java folks into mismatched braces, you have my sympathy, but if not, please join the rest of us in the 21st century. We have large screens, and we don't need to defile our code just because that's what was required in the 70s! Unless you're coding on a 12" laptop (why?!), it's just silly.
To follow this though to completion, the Allman style is reasonable, but not grammatically correct. If you want to use the best bracing style you need to look up Whitesmith. Here's a great description that I could have written myself (but didn't):
http://www.komputado.com/eseoj/1tbs.htm
Please note this important part:
"A statement is either a simple statement or a compound statement. A compound statement is defined as a block of statements grouped together by braces. Thus the braces are part of the compound statement, NOT PART OF THE GUARD OR CONTROLLING STATEMENT — the braces are paired, one opening and one closing, and so should be at the same level of indentation— and the indentation of the braces should match that of the statements in the block, giving...
Code:
if (condition)
{
statement1; Whitesmiths Style
statement2;
}Yes I probably sound kind of pissy about this, but it's a conversation I've had with many people over many years. And over those many years I've used ALL of the other styles at some point. And realized their weaknesses. When you have an independent project that is not ruled by some kind of crappy corporate coding standards, give Whitesmith a try. I GUARANTEE that most of you, if you give this method a real shot for a few weeks (long enough to wash the stench of other bracing systems out of your brain), and are not restricted by corporate standards, or twerps, you will never go back. And you will wonder why on earth anyone would even dream of using K&R.
Last thought: remember, this is the only bracing style that actually MATCHES THE GRAMMAR OF MOST LANGUAGES!
</rant>
Thank you for the rant. I think code that follow the conventions of the language is the most readable.
By the way, try your style in JavaScript. You'll have a tremendous amount of fun with return statements and implicit semicolons
This discussion was surprisingly rational and dispassionate until you showed up lol. Thanks for the link. I'm still trying to figure out my own preferred coding style. I'm using Allman, but I'll give Whitesmith a try and see how it goes.
One style suggestion I've tried and really like is to use a space buffer inside the parenthesis used for syntax purposes, but to omit the space buffer for parenthesis used to control the order of operation. I got this tip from Uli Kusterer's article on coding style. If there are some nested function calls with parentheses used for order of operations mingled together, it lets me quickly see what belongs to what.
I can't believe how passionate some people are about things like indents and curely braces. It really doesn't matter as long as it's consistant. Any decent programmer should be able to read code just fine using any of the well known styles (including K&R). "Don't sweat the small stuff".
Without trying to be antagonistic (really!), this is a silly comment. Readability is not and cannot be a function of language conventions, given similarly structured languages (i.e. not considering odd stuff like lisp or APL, etc.) Code readability is what it is, for a given set of similar languages. That said, it's a topic that could, and probably should have much more formal study than it has.
Your statement might be reasonable if you substitute the term "likable" or even "desirable, in many cases" for "readable". Then it's a subjective thing, and allows for things like herd mentality and just going with a standard because it's better than chaos. Which is, sadly, true.
By the way, try your style in JavaScript. You'll have a tremendous amount of fun with return statements and implicit semicolons
Nice try, but fail. I've written tens of thousands of lines of JavaScript in recent years, ALL using Whitesmith. And I've supervised other coders and developed corporate coding standards for multiple companies, over the past nearly 30 years. You're not going to win this argument, other than just saying nyah, nyah, I like my way better. And with that, I cannot argue!
ps. no idea what implicit semicolons have to do with this conversation, but if you worked for me and purposely used them in JavaScript with any regularity you would be looking for a new job.
New line
I personally use put them on the new line because it makes it so much easier to see what section of code your loops are covering. It's certainly especially helpful when you start nesting for loops within one another.
As a slightly side note, I also really enjoy IDEs that will highlight both the open and close curly brackets of a statement when you border your cursor to one of them.
I personally use put them on the new line because it makes it so much easier to see what section of code your loops are covering. It's certainly especially helpful when you start nesting for loops within one another.
As a slightly side note, I also really enjoy IDEs that will highlight both the open and close curly brackets of a statement when you border your cursor to one of them.
Yeah, LOL indeed. I added a smilie the the /rant to make it feel more like it was intended.
You're welcome, and thank you for being open enough to give something new (actually, very old) a try. Many people are just too stubborn to experiment and look for improvements in their toolsets, no matter what field they work in.
When you're trying it out, just remember that you are doing multiple positive things.
1) allowing your code to model the language. i.e. in almost all major languages, the BNF states that the braces are part of the statement, or compound statement, NOT the conditional.
2) you are keeping the braces aligned, which is just plain common sense.
3) you are minimizing the littering of the gutter (somewhat liberal use of the term) with braces, while still allowing them to remain aligned. This allows your eyes to scan the most important control words at the left edge of the code much more easily without interference by the braces, which, as long as they are properly matched, are in fact a distraction from the important stuff, which is the flow and code itself. It's all about readability.
Hope that makes sense.
That's a decent article, and I would agree with a lot of what he wrote, especially in terms of the use of spaces in relation to various uses of parentheses. I generally recommend very similar to what he does in those cases, with the exception of keeping the space after control words (but not function names). "if" is just to short to stand alone together with a parenthesis, like "if(". Again, it's a readability thing.
Good luck, hope to hear back from you here at some point in the future.
I think of code readability as the ability of the programmer to write clear code. I also think that it comes with experience and is impossible to formalize. Curly braces is the least of this but when people don't follow conventions for the given language it scares me. I immediately suspect them of trying to write in the style of whatever language they first learned and not really bothering to learn the language they're actually coding in.
I go for the principle of least surprise unless there is a really good reason not to. Curly braces placement ain't one of them
You're sort of proving my point here. I do enjoy a flame fest as much as the next guy, and if curly braces is your most important problem, I congratulate you. It isn't mine.
Regarding implicit semicolons and return statements, let me provide you with an example:
Code:
return
{
status: true
};The above is what I'd imagine Whitesmiths style looks like in JavaScript.
Code:
return {
status: true
};...And this is what it should look like. The problem with Whitesmiths style in this case is that the JavaScript interpreter implicitly inserts a semicolon on the same line as the return statement. Unfortunately, both code examples are perfectly legal and the interpreter doesn't warn you about unreachable code. This results in the first example happily returning undefined, which is quite subtle, thus potentially causing subtle errors. I'm amazed this hasn't bitten you.
By the way, this example is lifted from Crockford, Douglas: 'JavaScript : The Good Parts', Appendix A.3 (Appendix A is entitled 'The Awful Parts'). An excellent book on the subleties of JavaScript (but mostly about the cooler features).
I mentioned JavaScript because it is the only popular language I know of where the placement of curly braces is significant. Granted, this is because some of the designers of the language were clearly possessed by demons. Such evil cannot come about by mere incompetence.
In conclusion, I don't think I fail. (and I already have a job)
This made me smile. Let me slightly rephrase: When I see people stick up for K&R, (regardless of language) it scares me, I immediately suspect them of trying to write in the style they first learned, without bothering to consider that other styles can be better.
Of course the reality is that on many projects you are going to be restricted to some kind of corporate or group standards, and then you just have to suck it up and do what you need to do. But my recommendation to the OP (and to others who haven't succumbed to the herd mentality) was that if you have an opportunity to do so, be open minded, and you may be surprised.
It's a pet peeve, that's all. And far from the most important of problems, it's just an easy one to rectify, which is probably why it's so frustrating.
Stepping back along that vector, another pet peeve: if people would learn to name their identifiers to allow others to infer their purpose, life would be so much better! Verbosity is a virtue! This can be taught, although it's harder than merely adjusting bracing/indenting style.
Of course the biggest problems are related to people who just can't organize their designs in concise and reasonably easy-to-follow ways. But that's very difficult to fix because it relates to how people actually think, and how organized they are.
Got it, the example makes your point clear. And makes me much more confident that you don't do silly things like using implicit semicolons on a regular basis! As if you care what I think...! LOL (FWIW, I wasn't looking at your username when I replied - I've read many of your posts, and they're generally very good; and the "you" at the end of my earlier post was supposed to be in the general sense, not you personally, although looking back it kind of reads that way)
Back to the topic. This issue is moot in our standards, because if you require the use of parens with return statements, this horrible case never comes up. We recommend using parens with all return statements except when there is nothing to return, i.e. "return;". Yeah, that's a tiny bit of inconsistency, but some habits are very hard to break, and it's not harmful.
LOL. Indeed. I'm sure there is much we can agree on - OTHER THAN bracing style. ;-) And people need to be adaptable. If you worked for us you'd have to switch styles, and I think over time there's a good chance you would come around. You wouldn't be the first.
In conclusion, I don't think I fail. (and I already have a job)
And I suspect you are good at it.
I've changed my style over the years (I don't even think it was a conscious decision). I started out using a new line for everything. Now I'll sometimes use a newline for a switch statement and not for other control statements. Go figure!
Cheers,
Steve Kochan
Funny, I do the inverse. I use new line braces for everything, and will change any code I get that is written the other way as I find it nearly impossible to read. The only exception is for switch statements, where I keep the brace on the same line as the switch. However, I only do this because Xcode's auto indent is broken for switch statements with the opening brace on the next line and it annoys me.
I'm one of those weird pascal programmers that use defines to make C code look more like pascal:
Code:
if (something)
then
begin
// blah
end
Do you work alone (as a private consultant)? Because, no offense, but that would piss off a lot of other programmers who had to work with the same code.
Yes, how did you guess?
It's strange though, one of things I produce is an open source library for communicating with seismic recording systems. There are least two projects developed by 3rd parties that use that library and I've never gotten a complaint about my code formatting.
I do same line. We have no company standard, so everyone does their own thing and it's quite common for one of our source files to have a mix of both since everyone does what they prefer.
There's nothing I hate more than the one-line if statements that don't use any braces:
because in the future, that if/else block might expand to more than one statement per block and then you have to add the braces anyways, so just add them from the start. And, if it's not properly indented, it just adds to the confusion, and yes, I have seen:
That's just....wrong. Don't do it.
There's nothing I hate more than the one-line if statements that don't use any braces:
Code:
if (whatever)
do something;
else
do something else;
continue doing stuff;because in the future, that if/else block might expand to more than one statement per block and then you have to add the braces anyways, so just add them from the start. And, if it's not properly indented, it just adds to the confusion, and yes, I have seen:
Code:
if (whatever)
do something;
else
do something else;
continue doing stuff;That's just....wrong. Don't do it.
I do when it makes it more readable, for example when it's part of a big set of related constructs:
Code:
if (var1) function1a() else function1b();
if (var2) function2a() else function2b();
if (var3) function3a() else function3b();
if (var4) function4a() else function4b();
// ----- 8< -- snip snip -- 8< ---------
if (var19) function19a() else function19b();
if (var20) function20a() else function20b();(I chucked together a silly example, but I have seen instances of code where this makes sense.)
Fair enough.
It's always good advice to be open minded. I really don't care much about curly braces so I won't object to any company standard as long as it's not completely insane. Chances are, there's probably something going on that I care about more. I try to pick my battles.
I couldn't agree more. Modern IDEs have code completion and refactoring tools so there really shouldn't be any reason not to use descriptive names. Also it might cut down on the amount of comments you have to write. Not that comments are necessarily bad but sometimes you forget to update them when you change the code which makes them worse than no comments at all.
I bought Clean Code by Robert C. Martin some years ago and even though I don't agree with him on everything, it's an excellent book. If I had any clout at work, I would make it required reading for all developers.
I think we misunderstood each other. I agree that implicit semicolons are evil and should never be used intentionally (at least not in JS - I tend not to use semicolons at all in Ruby). And I do care what you think
Coding is a craft in many ways and one ignores people with 30 years of experience at one's peril. As long as people don't take criticism and disagreement personal, I'm all for heated discussions. One thing that really annoys me, however, is when the experience card gets pulled. There's really no way to respond to that as fairly new to the business. One thing that annoys me even more is when the more experienced developer turns out to be right But again, that comes back to being open minded.
I would never use the second approach. As mentioned,
Code:
if (cond) {
fun();
}is much better. I tend to not use the first approach either but in Ruby and Perl you can do
Code:
fun() if (cond)and
Code:
fun() unless (cond)This I do use because IMHO it is more readable. I would never use if-else constructs as one-liners.