Should you place curly braces on the same line as the statement (cuddle), or on the next line? It’s a debate that has raged for years, and is unlikely to be resolved until curly braces in code become obsolete. Despite that, I thought I would share my opinion on the topic.
First though, let’s look at both sides of the argument. I will try to represent this as fairly as possible, despite my own bias. I’ve numbered the arguments, so it’s easier to reference them in the comments.
Same line (cuddled)
function foo() { // same line example. if (a == b) { ... } else { ... } } |
Arguments in favour of same line formatting:
- More readable because it reserves vertical whitespace for the developer to visually segment logical code blocks.
- Code is more vertically compact, which allows you to view more lines of code at once.
- Reinforces the logical meaning of the code, by associating the brace with the statement it opens.
Next line
function foo() { // next line example. if (a == b) { ... } else { ... } } |
Arguments in favour of next line formatting:
- More readable because it’s easier to identify the start of code blocks, and easier to line up start and end braces.
- Reinforces the lexical and logical meaning of the code, by more clearly identifying a code block.
- Separates multiline statement declarations (ex. function declarations with a large number of parameters) from the code within the block.
My take
I’m personally a firm believer in the cuddled approach (I’m a cuddly guy – ask my wife), for all three of the reasons stated above. I like being able to see more lines of code (#2, particularly when editing on a laptop), I would rather break my own code into logical groupings with white space than litter it with breaks based on a rigid standard (#1), and I think that the statement is a critical part of the block which should be directly associated with it (#3 & #5). I also believe that wherever possible grammar for code should parallel grammar for writing, and I see the opening brace as being similar to a colon preceding a bulleted list. In essence it is saying, I am ending my qualifying statement, and what follows is the list of things it applies to. You wouldn’t put the colon on the next line, or as the first item of a list.
I don’t agree with the argument that it’s easier to see blocks with braces on the next line (#4) – if you can’t pick out the start and end of an indented block of code, you need to increase your editor’s font size. Some people argue that the benefit is that if a developer doesn’t indent correctly you can still match braces, but where’s the guarantee that a developer that can’t indent correctly will adhere to your brace standard correctly. Not to mention that most code editors include brace matching and code folding.
There also seems to be a lot of inconsistency in how next line formatting should work. Some developers indent the braces (which is heinous), some don’t. I’ve seen a number of developers use next line for most things, but break the standard for things like else and do/while statements, using something like this:
do { ... } while (true); |
When they should really be using this:
do { ... } while (true); |
The former example doesn’t violate the idea of making it easier to visually pair braces (#4), but it does fly in the face of the idea that a code block is a self contained entity (#5). A major argument in favour of cuddled braces is associating the statement with the block, which should be equally valid whether the statement is before or after the block.
I have yet to see a developer that adheres to same line formatting for braces invent exceptions to the standard. While I’m sure there are some that do, it’s a whole lot rarer, and more difficult.
On the flip side, Adobe has chosen to adopt next line formatting for curly braces for whatever reason. This means that if you use next line formatting, your code will adhere to Adobe’s internal standards. FlexBuilder also seems to only support next line formatting for its auto generated code, which really pisses me off (anyone who knows how to fix this, please comment!).
At the end of the day, the most important thing is that you are consistent. If you have to swallow your pride and adopt a standard that you don’t agree with to mirror the standards of an existing codebase or company standard, just do it!
Feel free to post your preference, and reasoning in the comments below.
I think I might write a few other articles detailing my thoughts on frequently debated code standards (single or double quotes, single line if statements, tabs or spaces, etc).
As a programming (at least what I’d consider programming) noob – I find the cuddled approach easier to visualize and understand. Actionscript, javascript, php, id doesn’t matter – cuddled seems the most logical.
I don’t think it’s a matter of “right” and “wrong”, but of personal preference. I prefer next line braces ever since adopting them almost two years ago, so I’m somewhat biased.
IMO, it breaks code into logical chunks and therefore is more readable. If you want to see more code at once, you can always rotate one of your monitors to portrait (as I do) and code on it. Being able to see more code is nice, but not at the expense of the code you can see being compressed.
I do think it’s funny that this topic is as hotly debated as Mac vs PC. 🙂
I personally code Next Line (since 1993, mainly C/C++).
I do it for reason #5 mainly, but also for #4.
Since AS doesn’t have block level scoping, I actually find it a somewhat misleading in AS code.
My personal preference is for a language like Python, where the language authors simply picked a format. (Python is same line, BTW).
I don’t know why I’m even commenting on this (since there is no right answer).
Definitely cuddled for me.. the opening brace on a line by its own just seems kinda lonely, and a waste of space, and I have to mentally tie it back to the statement it belongs to. Also more meaningful lines per screen is a factor.. I can’t use my laptop in portrait mode !
Indeed, my golden rule of programming is “there are no right answers, but there a lot of wrong answers”. Still, I think these types of discussions are useful for developers that are trying to decide which standard they want to follow.
Again, purely personal preference, but I don’t buy into the “logical chunks” argument. Indenting already visually identifies code blocks. I prefer to use vertical white space to identify functional blocks:
// do some stuff:
var a:Number;
var b:Number;
// do something else:
var c:Number;
while (a > b) {
a += b-c;
b *= 3;
}
// do another thing:
c = b;
Note how the tabbing identifies the logical block, while the whitespace clearly identifies the functional blocks. This is obviously more heavily broken apart and commented than real code (and the code itself is meaningless).
Next line braces more pleasing to my eye and therefore I use them.
I’m on the next line side. I went to school for design and my eyes were trained to look at type in a certain fashion. Particularly, I was trained to look at small portions of type, and also to look at the overall body of type as a composition. My personal tendencies have led me to enjoy the way the overall composition of a class looks like when using braces on the next line. It ends up being easier for me to skim and get a quick glance of things and overall, in my opinion, looks more elegant.
I think this topic also goes hand in hand with when and where to use white space. I’m a big advocate of using white space as it makes type easier to read when used properly. In my experience, developers who use the cuddly technique often don’t use enough white space either. But again, this is all just in my experience and my humble opinions. To each their own.
I’m a cuddler. Looks visually pleasing to me. And like most people, it’s what I’m used to.
I also am a cuddly guy.
Less lines is better.
Next line is right. Same line wrong. End of story.
Now let’s talk about tabs vs. spaces.
🙂
For the past several years I’ve been using the cuddled approach in all my coding, but this autumn I decided to give the next line approach a try.
Reasons:
1. I finally got myself a copy of Flex Builder, and it used that convention by default. (btw. I would also be interested in knowing how I could change the default code formatting, anyone?)
2. Reading the Flex Coding conventions and best practices document said that any components you create and distribute should use this convention in order to comply with the Flex standards.
After having used the next line convention now for about 5 months, I’ve come to the conclusion that it really doesn’t matter that much to me. It was fairly easy to switch over to reading and understanding code that was written with the next line approach, so your arguments #1 and #4 would just fall through for me. #3, #5 and #6 are things that I haven’t considered before (not consciously at least), so they would be removed from the list as well. #2 I do agree with 100%. Using the cuddled approach makes the code more compact which means I can view more lines of code without having to scroll, which makes reviewing code faster. There really isn’t much point in an simple if-else statement taking up 8 lines of code when it can fit on 5 lines. The next line approach does make it easier to read an if-else statement that spans large blocks of lines (say 30-50). But if your if-else statements are that long, then I’d say it’s probably time to re-factor your code anyway.
In the end, I totally agree with your conclusion that the most important thing is to be consistent. When viewing somebody else’s code, you typically learn the convention that developer has used reading the first couple of lines of code. After that I’d say next line or cuddly doesn’t make much of a difference, provided that the developer has been consistent.
“Now let’s talk about tabs vs. spaces.”
There’s no such discussion. Spaces are wrong. End of story.
😀
ps: Cuddle all the way for me too!
I am a next line person, but in a good IDE I’ll go either way.
The idea that cuddled gives you more control over whitespace (1) is true, but if you aren’t using whitespace around a guaranteed block of code then what are you using it for?
I can see the argument for more lines of code is valid (2), however I’m sure you also have limits with what you are willing to do for that (eg I never have more than one statement per line, in spite of that being compact and legal).
Mostly I use it because in IDEs that don’t autoformat on close open or brace, I have at least 2 moments per day where I am going up and hunting for braces. It isn’t that big of deal, but it isn’t exactly productive either. I originally used cuddled to save paper when I printed code, but about 5 years in I realized I never print code.
One thing not mentioned in the ‘no braces for a single line of code in a block’, which I also never allow myself to do — another fine source of occasional needless bugs. I’m also not totally sold on the python style indent instead of braces, but I can see the attraction.
Also I don’t think it is that necessary for the whole company to follow the same standard. Mostly people ‘own’ sections, and I think honouring that persons preference in that section is a valid way to go (as long as it is reasonable, neat and consistent). I am way more productive with ‘next line’ and I know others that are the opposite — so why hobble people? I think you get way more out of happy coders than you get out of standard braces (assuming the work is sectioned). Maybe there should be mode in an IDE that allows you to work in your brace pref, but silently save in the original.
Like you and others said, it is obviously an opinion thing. I can’t right off the bat see where to change that in Flex though! That is crazy, it should be in blinking lights in the pref dialog (like eclipse). Regardless of my pref, it is a choice, both are valid. That reminds me of VS now auto opening docs on the left, with no second option — someone decided that was better (aka easier to code). Totally f’n stupid, that trips me up 10 times a day.
I like to use “next line” on everything outside of the “function” level. It helps me quickly find the function or class I want to modify in the document. Inside said function, the code blocks are usually “same line” or very compressed for readability, unless they are crazy huge loops or if statements that need visual clarity.
function someFunction() : String
{
for(var i:int=0;i
Next Line! I used to hate them, but now I can leave them.
I vote cuddled.
I’m a bit odd though, because I normally will do this:
if (a == b) {
…
}
else {
…
}
Logically I like the cuddled, but as I code (I guess it’s just habit), I start my else on a new line.
Next line for me. I hate cuddling 😉
Much easier to read the code IMO, although I did used to use the cuddled approach I made the switch and will never switch back.
I prefer MOSTLY the cuddled approach. EXCEPT when defining functions.
Case in point:
function myFunction():void
{
if (…) {
…
} else {
…
}
}
I’m with Evan Mullins… I can’t stand having the else on the same line with the preceding if’s closing brace.
I also indent the closing braces though.
There is a middle ground, too. At my first job (building pre-Flash Java banners), there was a coding standard that required next-line braces for the top-level class declaration, and same-line braces for everything else. I thought it was weird at first, but it grew on me. It’s not too different than the convention of capitalizing the class name and lowercasing everything else, which is a common practice. And in Flex Builder, it means I only have to “clean up” the default constructor because everything else is already the way I want it.
Either way, cuddle or no cuddle, can we all agree not to leave the braces out completely even if the compiler lets you? I’ve seen seasoned programmers struggle for hours with bugs that were caused by forgetting to add the braces along with that new second statement inside an “if”. It takes just one bug of that scale to equal the time you might have spent adding thousands of braces up-front.
(Just a suggestion) 🙂
I’ll throw in my support for always using braces:
if (something) doStuff();
Just looks wrong to me, and is prone to injecting bugs when the code is refactored. This is even worse:
if (something)
doStuff();
Because its even easier to accidently start appending code to the if.
Vertically condensed cuddled code FTW! Anyone who has an easier time reading next-line formatting is obviously an alien and their opinion should be discounted.
I’m a lifelong cuddler. I cringe whenever I see next line braces.
People who use single-line if’s, (or two-line with no braces) should be shot. Like they dont care that code allways needs refactoring, lazy bastards.
The worst in coding is lazyness. And since everybody at the office has at least 17-inch screens the ‘this saves screen space’ argument is void and null. Scrolling vertically doesnt hurt.
Also: FDT ftw! Ctrl-F(ix) your crappy code!
Cuddle all the way.
I put my braces on the next line just because it gives more whitespace, which makes it easier to read for me.
For me cuddled braces make things a bit to condensed, since I write a whole lot of comments in my code (every block has one or more comments).
I’m wild, I use both. Depending on how packed the conditional statement, and contained lines are.
When I’ll use cuddled
if (burger) {
burger.eatIt();
}
When I’ll space it out.
if (cheeseburger.hasOwnProperty(‘pickles’) && soda.hasOwnProperty(‘pickles’)
{
cheeseburger.removePickles();
cheeseburger.addJalapenos();
cheeseburger.addHabaneros();
this.getGlassOfMilk();
cheeseburger.eatIt()
soda.putInTrashCan();
}
“Next line” all the time, and auto re-format the heretics who disagree!
For me the reason is purely visual – in most IDEs (FlashDevelop for example) you get a vertical grey line that joins the braces together down the left side of the code block.
If you’re a cuddly brace freak this grey line extends from the first letter of the code to the closing brace. If you’re a newline winner it does what it should logically do, it joins both braces together. This and the whitespace it delivers in the process means I’ll never convert to the dark side.
But hey, feel free to pollute your eyeballs 🙂
Richard – ah, but that’s part of the reason I like cuddling, because then the nice little grey lines connect the full statement, rather than orphaning the important bit. 🙂
On another note, what about inline conditionals? Or even yet, embedded inline conditionals. Speed at the expense of readability.
var cuddle:Boolean = true;
var newline:Boolean = true;
var choice:String = cuddle > newline ? “Cuddle FTW!” : cuddle == newline ? “Your preference.” : “Newline 4 life!”;
If you subscribe to the thought that cuddling is superior by it’s condensation, why not write all if-else statements conditionally and inline? I totally love conditionals, but I write in Allman (newline) indentation, I personally don’t care about saving space. Wikipedia has a nice article on the differences and why they exist -> http://en.wikipedia.org/wiki/Indent_style
I agree with Grant on this one. Cuddle those brackets for less typing and less scrolling.
Can you put up a poll for people to vote? Personally, I favor the former. It really irks me when something that could have taken up 10 lines of code instead takes up 20. wtf is that?
I did the cuddly thing for several years before becoming enlightened and switching to next line… the code just looks cleaner. If you need more space, buy a bigger monitor 😉 Honestly, I don’t mind reading code the other way, just Please don’t put nest your else between two brackets i.e.
if( something ) {
doStuff();
} else {
doOtherStuff();
}
That just looks terrible.
Cuddlers are closer to Nirvana.
Not only they write pleasing code, they are also more beautiful, in and out.
Next line for me. My IDE highlights my braces, and they visually align for me. I develop on monster panels, so I don’t need to worry about saving lines of code.
I also do spaces for tabs. It’s much better – makes the code more portable 😉
Next line is better!
I do next line.
For those who argue against #5 and #4, indentations can lie. Next-line braces makes it clear which block the code belongs in.
If your text editor doesn’t have built-in brace matching, then it’s more difficult to spot un-matched braces if you use same-line.
Corporal cuddling for me. I’m not sure why but I find it just looks neater.
I like the cuddled approach, but flashdevelop keeps automatically formatting my code to have the “next line” curly brace and I’m just too lazy to change it, if at all possible.
Personally I prefer to mix the two for cleaner code.
public function foo() : void
{
if (a == b) {
//
} else {
//
}
}
THis allows my functions to have very clear line wrapping for start and end. All the code inside will be indented and statements can stand out as to which is a group of code.
There are really a lot more important things we could be discussing beside this trivial formatting question.
Besides, you’re wrong. Next line is the correct way. 😉
Cuddling or not, i’m in a full blown affair with autoformat… (but not the actionscript version that was removing empty lines.. ah!)
I agree that “cuddled” braces are easier to read due to compactness. However I have grown to prefer non-cuddled for a simple reason: debugging.
You can easily // the original and have the block always execute or create a new condition without having to mess with braces. You can more easily comment out else clauses with minimal typing.
Cuddly? Ha. I prefer my braces sharp and painful on the next line, thank you very much.
I’m a (mostly) K&R bracket style guy (I break the pattern and cuddle function declaration lines too) so not being able to (read: not knowing how to) change FlexBuilder’s default formatting drives me nuts!
Might be time to throw some of that flash guru weight around over at Adobe, Grant. 🙂
I use both:
if (a == b) {
…
} else {
…
}
function blah(params): returnType
{
…
}
Just gives me better visual acuity when scrolling through code. Tends to allow return types to pop out a bit more as well on function declarations.
I used to use same line curly braces for everything until I started moving away from procedural code towards OO based code.
I think I get the best of both worlds 😉
Cuddle all the way! I rely on proper tab formatting to visualize open and closes, but this is a debate that will never be solved, I’m just glad we have brackets though.
Personally, I’m all for the cuddle, but i don’t care when reading some else’s code. My old boss, on the other hand, nearly blew a gasket when discussing how much he hates “cuddle”.
What Matt Giger said! Grant left out this very important point in his list.
Showing code listings on the Web or in Books it’s fine to use cuddled because there’s a need to save space but in your Editor … why would you? There’s a vertical scrollbar and you got endless amount of space.
I’m a next line man. I used to be a cuddler but converted a few years back. I just find it easier to read.
Next line all the way 🙂
I find that the code looks neater and makes my eyes happy..
function doSomthing()
{
if(a == b)
{
trace(“Hello!”);
}
else
{
trace(“Cheese!”);
}
}
vs
function doSomthing(){
if(a == b){
trace(“Hello!”);
}else{
trace(“Cheese!”);
}
}
For me the top one is easier to read and look at (even though it takes up more white space)
Cuddle for me as well ! I think a good tab management is the best thing you can do to read everything easily.
I like to split it on a new line cuz I like the white-space. It makes it easier for me to scan the code and see the blocks of code that are important. I also insist on using divider-line comments between functions. I’d be interested to see if it coders who have come from a design background that do this.
I’ve been coding for more than a decade and working with flash for as long. I was there when actionscript was first called actionscript (not literally, but I was thrilled when actionscript adopted dot notation.)
I am a cuddler, why? because I don’t need help reading my code, or finding my code. Here is how I figure out what my code is doing…
//I leave a comment in it
simple! And here is how I find what I am looking for…
[CTRL]+F
Even more simple. Scanning code to find something when you write hundreds (or in my case thousands) of lines of code is like skimming a book for a word rather than looking in the index. Seriously? If you need it to visually look a certain way to manage your code then either (1) you don’t write a lot of code or (2)you are so new that you don’t know how to architect your code / classes.
I am fine with non cuddled code, but honestly, to me there is nothing worse tha being distracted with code that looks like it is on training wheels (i.e. tons of whitespace, overcommented and broken apart):
function someFunction ( myNumber:Number):Number
{
//add one to the number
myNumber += 1;
//return that number
return myNumber;
}
This is fine for someone who is learning to code, but if I am going to read your code, please, clean that mess up before sharing it with me:
/* Author: smcdonald
Date: 11/25/2009
Desc: Adds one to a number */
function someFunction(myNumber:Number):Number{
return myNumber += 1;
}
Cuddling? Really? And to think I used to look up to you…
😉
You are a cuddler? Argh, now my world broke. 😉
One argument you missed for newline is one I use alot in testing.
Using new lines it is very easy to comment out a statement and then run the code all the time (mainly for tests).
//if (_isBroken)
{
fixIt();
}
Also, using newline the short comments are easy to put on the end of the line, this somewhat break the standard though, but I like to do this (if not doing a larger documentation in javadoc style, this is more applicable to if/then/else statements).
function fixIt():void //will fix the bananas
{
var mBanana:Banana = findBanana();
}
I started off as a cuddler in ’95, but switched to next line a year or two later. While both have their merits, my eyes are able to better scan over large sections of code when it’s written in a next line format. I like Grant’s simile to colons/lists, but I feel he’s overlooking an important element in code blocking.
Yes, when writing a list, you’d hardly have your colon on its own line. But then what about the end brace? It sits all by its lonesome, the afterthought of what should be a powerful statement. An ill-explained ellipsis. It’s that asymmetry that always got to me and led me to write next line. Now my braces aren’t a colon and a trailing ellipsis – they’re the Spanish equivalent of an exclamation, marking my beginning and end with panache!
I’m most definitely a cuddling coder. It clearly saves space and puts less stress on your scroll-wheel finger and for me makes the code easier to understand.
I hold the complete polar opposite opinion and attitude to that of smcdonald (except on the over-use of comments). May our coding paths never cross! 😉 …
I write and like to see well spaced code. I want to understand it at a glance without having to squint at scrunched up code, or resort to ctrl-f in a messy block to find what could and should be obvious and clear. I also ensure my argument lists are neatly listed in tabbed vertical alignment etc. Horizontal scrolling is evil in general, and especially when reading code. Anyone writing Cairngorm stuff is already having to write long lines before starting to put arguments next to each other on the same line. There are no prizes in my book for the most code you can fit on the least number of lines.
Would be easier to debate examples here if code-samples submitted through comments weren’t stripped of style.
IMO, I prefer next line. But in the end it’s just personal preference, I don’t see any true benefits of either style.
Shame you didn’t have a voting thing enabled for this post, its got a great response.
Cuddled!
*Next line*, all the way. I used to be a cuddler until my code complained about being smothered. Or wait, was that my ex-wife?
Anyway, I can’t believe Grant came down on the side of cuddled braces. His error on this issue calls into the question the merit of all his other articles, and requires me to rethink anything I’ve learned on this site.
😉
Cuddled. Only way to go.
I’m a next-liner. I see the braces as “bookends” rather than “colon/list”, so next line has always made it easier for me to read, regardless of indenting or font-size. @ brent dearth: Yes, I’m a very happily naturalized alien from the planet Xargon 😛
Cuddled for everything except package for me
I now use the next line approach because I find the cuddled approach cluttered and ugly. That is the only real reason.
I don’t agree with any of the arguments made for or against either style because they all seem trivial. What difference does it make? I agree readable code is important but being picky about what line a brace goes on is ridiculous.
The response to something so meaningless is amazing, it’s even got me responding. The mind boggles 🙂
I’ve been using the cuddle approach since I started coding, but a year and a half ago I started coding using the next line approach, just to give it a try… And after some times I kept it 🙂
I think when you are used to the same line, the code using next line is “hard” to read but then IMO after a while it’s definitly more readable (#4 and #5) ( no lost curly braces 🙂 )
But again as everyone said it already, it’s just a matter a personal preference.
What about having a white/clear background vs black/dark one? hehehehe 😀
These days i dont like braces.
If i must though, I only huggle within methods functions.
I realise this break’s “consistency” for the whole file, but its a simple convention to follow, and provides benefits of both worlds where they need it most.
Personally, I don’t find the whole braces thing nearly as irritating as people not spacing out operators.
Since I spent a lot of time coding without syntax highlighting (How?…), I ended up putting in a lot of white space. Now, things tend to be more idiosyncratic, but consistently so.
Function params’/arguments’ parens are always spaced out. EG function foo( bar :Bar, baz :Baz ) :void
Math groupings are not, however, but they’re still separated from other things outside.
bar.baz = vta( 4 / (2 * Math.random()) );
Variable/function labels are spaced apart from the identifier, too, as in the previous previous line. Hashes/anonymous objects have their members taking the colons, though. So you have
var baz :Baz;
but
var baz :Object = { a: 0, b: ‘a’ };
Also, since starting on Python, most strings have been single quoted. This doesn’t matter, of course, until leaving the realm of ECMA Script based languages. Still vacillating on that, though, I think.
Code tends to get spaced out into semi-logical blocks, especially long runs of variable declarations and import statements. (Never use import foo.*!)
Also, Event handlers always have a capital E :Event, not e :Event. Eh.
Oh, I’m not a cuddler. 😛
But as I’ve said, that’s not nearly as irritating as (not) spacing out stuff. Syntax highlighting be damned, I need space around them.
Flex Builder assumes the next line format. I wish there were a setting to turn that off or edit the templates. I’ve looked everywhere I can think of and never figured out how to do it. Instead I have to go “fix” the code every time I create a class.
I agree that it’s totally a preference thing. The only problem that I’ve run into is occasionally working with people that do the next line thing. They asked me to adhere to their standard. I replied that it would cost them an extra $10/hr. I ended up giving them cuddled code. 🙂
Worse case scenario is I’d write an AIR app to just convert the code for me.
Cuddler here, to the extreme. I like to match the patterns on screen with those inside my head. No room for loss of screen estate.
It’s interesting how the next-in-liners are so much more verbose…
I have been a Cuddler but for a year spent in Next Line land. Vertical compactness is very important for me in eclipse land with navigator, problems, console, etc all open. Also Cuddling is closer to def-end of Ruby which I like the most.
i use and work with same line Braces.
Used to it.
i think the most interesting pattern to emerge here is the “i used to cuddle and now i drop.” I fit this form and I don’t see anyone saying they’ve gone from dropping to cuddling…
Cuddling looks cluttered and disorganized to me- there’s more wiggle room. Touching the type or a space after it? That coupled with all the combinations of how you format your method’s return type make it, across multiple developers, inherently disorganized. Whereas the dropped brace always sits clean and tidily by itself on the next line.
cuddle +1 here, if you think about it, is way cleaner/easier to read and code when using cuddle, even better if you use tabs, which is no problem as any decent IDE with auto formatting will add tabs for you anyway.
On the other side, if using note pad/text edit or any other no frills text editors( btw. hardcore coders seem to prefer this),with no auto format, it makes more sense to use next line… it looks awful though.
Well first off, the colon/list approach doesn’t make sense. You can’t claim that positioning the brace on the same line is following proper grammar and then promptly ignore the brace at the end (and the additional semi-colon which I’m comparing to the comma in the example below). You end up with horrendous grammar that is completely incorrect.
In correct english, you do not do the following:
The list of ingredients is:
cheese,
apples,
pastry,
:
Secondly, if you do think that cuddling is important in the layout of code and saving space then why don’t you cuddle everything?
Why don’t you write similar statements on same lines?
my_clip.alpha = .5; my_clip.x = 100; my_clip.y = 250; my_clip.rotation = 45;
Why don’t you cuddle the last brace?
function something():void {
my_clip.alpha = .5;
my_clip.x = 100; }
In the examples show you don’t do that, so why on earth do you break that coding convention that you use _everywhere_ else?
Cuddling seems illogical because there are a lot of people claiming the next line approach is ugly and looks awful and then using it everywhere else in their code.
Why use one rule for one coding situation and another for every other situation? Coding conventions and best practices are about consistency, are they not?
Oh and if you want more space why not just fold up your code, why break this consistency?
I don’t mean this post to come off as anti-cuddling. I’m sure you all have some good answers to my questions but I would like to hear them as it just doesn’t make any sense to me.
km,
You’re engaging in a logical fallacy.
Your question is akin to asking why people that believe curly braces should be next line don’t apply the same white space logic to all of their code. Surely if code is easier to read with a vertical break before every code block, it would be even easier with a vertical break before every single statement?
Cuddling the brace includes it as part of the logical statement it helps define (“if this condition is met then run this code”), whereas your rather silly examples do not help to clarify the code. As is obvious from the seventy some comments above, the clarity of cuddling is debatable, but I don’t think you’ll find anyone arguing that putting all your code on a single line makes it more readable.
When I first started programming (C/C++) in the late 90s, I was taught the next line method. That worked for me at the time because I was writing short small programs. Once your graduate to the bigger stuff, cuddling just makes more sense. It, in many cases, greatly reduces the extra lines in your code because you are not putting that single curly brace on a line all of its own. To loosely quote a movie, “You are putting the [curly brace] on a pedestal.”
Even when I moved to actionscript I have found it makes just as much sense as it did in C/C++. I am of the opinion that if you are a cuddler, you are much more likely to write cleaner more succinct code because you are always concerned with extra lines. Does this mean you will put multiple statements on the same line? No, but it does mean that you are more likely to combine statements that can be combined. This helps to reduce the number of unnecessary throw away variables.
Grant,
Thanks for the response. Yes I know I was being more than a little stupid and I didn’t word it very well, so I apologise.
No my rather silly examples don’t help clarify the code, which was my point. I feel that cuddling should be lumped in with all of those examples. However, you’re right, no-one is arguing in favour of the stated examples so it was a poor choice on my part.
I don’t like the idea of including the brace as a part of the logical statement because it is no more a part of the statement that the brace at the end or the code inbetween. All elements _relate_ to the statement but are _not_ part of it and I relagate all of the other statements to a new line, so why not the initial brace?
I also didn’t like the fact that you employed flawed logic with your analogy and chose to select certain parts of the code to parallel with grammar and certain parts to simply ignore because they didn’t fit with your view.
I mean code rarely parallels written grammar. For a start nouns begin with capital letters, a noun such as a variable name in code is always supposed to begin lower case. Coding practice is filled with differences like this.
It’s also interesting to note that you view the brace as a vertical break. I don’t, I always viewed it a just another statement. Out of interest, if you view it that way then why do you not cuddle the last brace? Is it necessary to have two vertical breaks between code blocks?
Why:
function hello() {
…
}
Instead of:
function hello() {
….
…. }
function anotherFunc() {
}
etc.. Which is no less clear, I mean languages like Python leave out the braces altogether and work just fine without them.
The bottom example would seemingly fit more with your point of view. I’m not trying to cause an arguement or anything, and I’ll happily admit that my logic is flawed again but was just intrigued.
Ultimately the whole thing is as you’ve mentioned more than once, a matter of personal preferance. Just trying to clarify my stance someone, so I don’t look like a complete fool 🙂
next line for me – Being dyslexic, spatial formatting is far more important to me that gramatically correct formatting. I like to be ‘Generous’ with my space/line returns. I generally find next line formatting a lot easier to navigate and read. Above and beyond that though is well commented, asDocs style, code!
Actually the last question was a stupid one again. You probably don’t cuddle the last brace because you don’t feel that is part of the preceeding statement right? And as such doesn’t help to clarify the code in your view. If that is the reason, I still don’t agree but am beginning to understand your view on this.
km,
that’s exactly right. Putting the closing brace on the end of the last line wouldn’t make sense (to me) because it is not part of the logical statement on that line.
Cuddled code to me says:
“I am making a statement that applies to the following:
this
and this
this is the end of my list.”
It’s not a direct grammatical comparison to a colon and list, but I included it for completeness. Note that bulleted lists are typically followed by a blank line (though of course they can be preceded by one as well).
Code does not always parallel grammar, but it’s nice when it does. The example you gave is actually a great one in favour of this. Instances/properties are named with a leading lower case, whereas classes are named with a leading upper case. This parallels english grammar where the abstract concept (ex. Man, God) are named with an uppercase, and concrete expressions of that concept (ex. a man, a god) are named with a lowercase.
That made me smile, we actually agree on the subject of grammar paralleling code except I’m a pessimist and you’re an optimist.
My view is that code should parallel good grammar but it never will so we might as well put up with it.
You take the more positive view of trying to get good form in when and where you can 🙂
Thinking about this some more, I think I view the braces as just another statement because I come from more verbose languages where you have to write endif or endwhile (BASIC….shudder, Lingo etc..) and I always put individual statements on new lines, that and as mentioned I don’t feel that the brace is part of the logical statement (afterall it isn’t needed in all instances, as in the example below, so how can it be part of the statement?).
The cuddled approach to me is the same as writing:
if (condition is true) my_mc.x = 100;
A statement following a statement, which I personally don’t like. And was why I made the (in hindsight, very silly) comparision with the following:
my_mc.alpha = .5; my_my.x = 100;
And so on.
Again thanks for the response and thanks for setting me straight on a few issues. It’s amazing how such a little thing sparks such an interesting debate 🙂
km,
not trying to pick on everything you say, but I think part of the reason I like cuddling is actually because of my early experience with xTalk languages (Lingo, HyperCard, AppleScript). With them, the statement is always the equivalent of cuddled:
if something then
do stuff
end if
Where “then” is effectively taking the place of the opening brace.
Or:
on myFunction param1,param2
do stuff
end
Which doesn’t have such a direct brace equivalent, but still fits the cuddled feel more than next line.
Cheers.
Fair point there but I think it’s just a different view.
When I came to C syntax languages, for me there was no direct equivalent to the opening brace. In the variations of BASIC I used and in Lingo (as you noted) the ‘then’ keyword isn’t required and I never used it.
So when I encountered the end brace (which I associated with endif, of course) I just decided to treat the opening brace in the same way – as an opening statement and as a result there was no way I was putting it on the same line 🙂
We’ve both come from a similar background and interpreted things in completely different ways. It happens.
Oh and feel free to pick away, I like it when people pick holes in my arguements and it makes me more thoroughly consider my point of view. It’s a good thing.
I’ve been a cuddler since day one but ever since I started using AS3 I’ve been using FlashDevelop who next line’s by default. I’ve reluctantly grown used to it.
I’m a longtime Java developer, and was a “next-liner”, then started working at a place with probably the best developers I will ever work with.
They were all passionate cuddlers (ewww that sounds a bit wrong!) and I got used to seeing good code in cuddle format.
When code is written well, with properly decomposed methods and well-chosen naming, you just don’t *need* that extra whitespace.
It’s also the Sun Java formatting standard, which never hurts.
And people saying “monitors are big these days” – they’re growing horizontally a lot more than vertically!
The way I see it…
Right:
function f (x) {
if (x
@idahotallpaul – you appear to be making a comparison between 1TBS above and the K&R style below (1TBS is actually a variant of K&R AFAIK). I think the comparsion is between the Allman style and 1TBS but forgive me if I’m wrong.
In the Allman style, every brace is treated the same by being put on a new line but you haven’t done this with the if statement so I can only assume that you’re referencing K&R.
You are right however in saying the the above example is more concise but it could be argued that the braces are not treated in exactly the same way. You give one brace precendence by placing it on the same line as the parent statement when it actually belongs as part of the code block that follows.
The main arguement behind 1TBS is that every statement that prohibits code insertion should be placed on a new line. Sound reasoning.
I’d also like to point out that no-one seems to have commented paddy’s comment further up. He makes a fair point about being dyslexic. I think people should realise that just because a coding style is readable to them, does not necessarily make it readable to everyone else.
I’m not arguing one way or another (no point) but just thought I’d comment on a couple of things.
Just re-read the comment above mine and evidently, the brace in the if statement in the bottom example was supposed to go on the line below. My mistake, the Allman style was being referred to. Other points still stand.
Don’t know why I bother, I meant that the main argument behind 1TBS is that every statement that prohibits code insertion should be placed on a single line, everything else on a new line. For example you cannot insert new code between the right parenthesis and the opening brace. I’m going back to bed and getting some proper sleep.
A bunch of stuff got dropped when I made that post – including spaces and the rest of those if statements – looked right when I pasted it.
First example was what is generated in flash CS3 auto format preferences when just the 4th and 5th boxes are checked. Second was with the top 5 boxes checked.
In my company, the flash team is part of the creative group (you know, ’cause AS3 isn’t programming or anything…). Asked a couple of our “tech” guys what style the flash team should adopt. It started a pretty sweet nerd slap fight between the Java and .net guys. I decided it’s probably best to just write code the way it looks good and makes sense to me.
BTW, anyone know of any good textmate commands to toggle between the different styles? The Tidy command from simongregory.com’s ActionScript Utilities bundle will de-cuddle, but I don’t know of one to convert it back. Thanks.
I believe it has more to do with personal preferences and the way one practiced standards when one start their programming career.
I have started with turbo c/c++ where I practiced non cuddled braces. However, ever since I have started coding in Java the lecturers used the cuddled standards which I found difficult to master at the beginning and now it has embedded in to my muscle memory without even I noticing the difference.
I have coded in a variety of languages/scripting langs such as c/c++, Java, JavaScript, PHP, ActionScript, VB, Pascal; (BASIC type languages doesn’t use braces) The only thing is, I find myself switching automatically to the standard I used when I started coding that particular language.
Which goes on to say cuddled or not how the programmer/developer interprets it is merely psychological than whether or not which method is the best.
Clarity to another is chaos to another – By me (of course [reverse holds – lol])
I use cuddled but i can cope with either, all i care about is indentation and consistency.
Regarding argument1:A developer can use whitespace to visually segment blocks of code using either style.
Regarding argument3: in next-line style the opening brace is still visually associated with the statement it opens by being immediately under it and horizontally aligned with it. There is an added benefit in the brace also being horizontally aligned with its closing tag. If one is searching for the opening brace that corresponds to a particular closing brace in next-line code, one need only scan vertically for the nearest horizontally aligned opening brace. Performing the same task in cuddled code requires one to scan both vertically (for horizontally aligned lines), and horizontally (for opening braces).
I disagree with those who say it is purely a matter of preference. Are typeface choice, letter-spacing, or text-color purely preference? No. They all have an impact on legibility and clarity. This does too.
One of a “good” programmer’s main concerns should be making their code easy for *other* people to understand, including those less brilliant than themselves. You may like reading things in 6pt. font-size, but you better not publish a book like that.
Do cuddlers find next-line formatting confusing? I don’t want to speak for everyone, but I suspect most do not, they merely dislike the extra space it takes up (which is not surprising given that so much of programming is aimed at minimal resource consumption). There are definitely those who find cuddled braces less clear, however, and so a greater benefit is served by using next-line style.
Question:
What if you are creating a complex variable (like an array of objects)?
Something like:
var thing:Array = [{p1:val,p2:val},{p1:val,p2:val}];
the left bracket will generally not be in a tabbed-friendly place… would you separate each object in its own line? where would you leave/tab a final right bracket?
(I cuddle BTW)
Cuddling is the only way for me, looks cleaner, and less scroll time!
It seems like it is often the older coders, dream weavers and PL/SQL guys that do not like the “cuddle” style. Back when, with languages like C, C++, PL/SQL, or Pascal, debugging consisted of printing out code and and drawing lines from brace to brace. IDEs are so much better these days. I haven’t printed code for years.
I have been in more than one shop where this was debated, always coming out on the side of my favorite, the “cuddle” approach.
I hate cuddling, if the closing brace is on a line of its own then so should the open brace…
As for the comment about older coders who don’t like cuddling…waffle! Go read Java How to Program by Deitel. Their H.T.P. series is brilliant and they don’t use cuddled braces. Why? It’s easier to read and they encourage best programming practice from the very beginning…
Unix and C started the better approach:
if ( condition)
{ .. something to do
}
else
{ .. something else to do
}
Unlike the cuddle:
if ( condition) {
..something to do;
..something to do; }
else { ..something else to do;
..something else to do;}
Yea, this looks SO much better. The lines don’t have headers to show you what you are doing. The indentation will obviously link what goes with what, but not here because the else pushes things a bit. If you don’t like the {} braces, then don’t use them. Go be a VB wanna be.
Cuddle in FDT, next-line in FB.
Now… another acute issue:
1] public function foo(bar:Object):int
2] public function foo(bar:Object).:.int
3] public function foo(.bar:Object.):int
4] public function foo(.bar.:.Object.):int
5] any combination of the above
And… where to place ‘override’?
I hate these debates. Programmers waste so much time reformatting or arguing over same line/next line and tabs vs spaces for eons. Actionscript, C, C++, Java, C#, javascript and many languages have to deal with them but it is refreshing when you use a language like Python.
In Python, tabs are forced and for that there IS NO curly braces needed, ever.
That might explain the amount of Python libraries out there, all the free time not discussing curly brace placement and tab vs spaces debates.
Personally I am cuddly and tab but I conform to the library that I am using when it is different. No point in wasting a life reformatting code.
Ryan – I agree completely. Stay consistent with the library or team you’re working with. I find it amazing (and a little entertaining) how emotional some folk get about this topic.
But of course anyone that uses spaces instead of tabs is incompetent.
😉
You have to put your curly brace on the next line in the next version of ActionScript or it won’t compile. I’m having them add that to the compiler.
“More readable because it reserves vertical whitespace for the developer to visually segment logical code blocks. ”
If you are using white to make logical code block chances are you should be writing more methods with more meaningful names. This will eliminate this reasoning.
“More readable because it reserves vertical whitespace for the developer to visually segment logical code blocks.”
I really don’t understand this argument. It should be: “It reserves vertical whitespace on screen, but I should really buy a bigger screen :-)”.
Code readability among flash coders is pretty bad, not to say horrible. If something should be done, it’s to focus that we all start to code better.
I prefer the next-line approach, simply, because it improves readability of the code. It’s visually extremely clear where the block starts and ends. I look for opening and closing brackets a lot. It saves time…… when looking for blocks of logic.
Compactness should NEVER be an argument, since that would also mean that you wouldnt recommend good OOP, breaking up methods into smaller, more compact submethods (which would always result in more lines of code in a class). Readability, crispness and visually easy accessible code are paramount for clean coding.
PS
This battle about curly braces is pretty trivial of course, but it never hurts to talk about coding conventions.
Finally, a great quote which i encountered last night while reading this book called ‘clean code’: “Professionals use their powers for good and write code that others can understand.”
@hatu: Haha… yeah, I wouldn’t want to cuddle a ‘package’ either :p
I too used to be a cuddler, but have since made the switch to the new line approach. Switching was the best thing to ever happen to me (well, next to switching from PC to Mac)
In my opinion it is much easier to read, gives the code within the block consistent padding, and is simply way more aesthetically pleasing. Yes, programming is a completely different world from design/typography… but I can’t help be more attracted to the beauty of the symmetry!
As for the argument that you can fit more code vertically… well that may be true, but isn’t necessarily a good thing. Fitting larger amounts of something into a smaller space might be great for technology, but I don’t think it is for typography!
Regardless, the matter is completely subjective… so do whatever keeps your OCD from ticking! 😉
My programming style has changed a lot over the years, and I find it’s just a personal preference. Currently, I’m in a cuddle stage.
I usually just use whichever method feels right in the moment. 🙂
hi Grant,
for me it’s cuddled, and I use this elcipse plugin,(it’s reformats with new lines by default but you can change it in the prefs) http://sourceforge.net/projects/flexformatter/
cheers
Cuddled. It’s nice and compact and some IDE’s even collapse blocks better when it’s cuddled.
As for the tabs vs spaces debate… set your tab key as four spaces. Now they are one and the same.
I’m a cuddler, and I particularly like how you pointed out that cuddlers generally apply formatting consistently while new-liners often invent exceptions like half-cuddling the else in an if/else or the while in a do/while.
I also find, when examining others’ code that new-liners make more indentation errors than cuddlers. Apparently, they have trouble reading their own code.
The problem with both of these approaches is that the curly braces are not part of the control structure grammatical productions for any of the curly brace languages. Curly braces are a grammatical production unto itself. They are part of a grammatical production known as “” (sometimes referred to as “”). Here is an abbreviated set of the grammatical productions that are found in C, C++, and Java.
::= | |
::= |
::= ‘if’ ‘(‘ ‘)’ ‘else’
::= ‘while’ ‘(‘ ‘)’
::= ‘{‘ “}’
I cant stand braces on the same line as the statement… it makes much harder to identify the start and end points of a block. I dont understand how you can say the cuddle approach is “more readable”. Thats exactly why it is not a good solution… it is LESS readable. Having the opening and closing braces line up makes it much easier to identify the block. File space on a new line is not an issue in these days of high storage and fast processing.
I use cuddled approach because it makes most of my functions resemble the 7-gun in 007 logo, making me feel like James Bond.
Next line brace is for pussies and communists.
I prefer the Next Line approach.
I don’t believe in being able to see more lines of code as a benefit necessarily. In fact, I think that’s conducive to writing large classes. If you find yourself scrolling a lot or feel the need to see more lines of code I think that means your method/class is too large and you have too much responsibility going on.
I have a similar reasoning for line breaks in methods. I don’t use whitespace line breaks to visually segment code within a method. I find this is also conducive to writing methods that do more than one task. The correct way to segment behavior is to break up the method into their own separate methods and call those logical blocks of code by their intent-revealing method names.
Just my 2c.
I prefer Next Line approach for braces. I think it makes it easier to identify blocks as stated earlier and I don’t believe being able to see more lines of code is necessarily a benefit. In fact, it may even be conducive to writing larger classes. If you find yourself scrolling a lot in a file or feeling the need to see more lines of code, the class probably has too much responsibility and the correct solution is the break it up into smaller classes, not cuddle braces.
I have a similar reasoning for within methods. I don’t believe using whitespace line breaks is a good practice for segmenting groups of statements within a method. If you have to segment groups of statements within the same method I think your method is doing too much and I would rather break it up into smaller methods, so that each method is doing one task. I actually don’t have any whitespace line breaks in my methods and as soon as I start to find it confusing to read I extract methods from it. Just my 2c.
Why put braces on the same line? I would always put the curly braces on the next line-never be on the same. It’s not wasting space…it’s on the hard disk-it makes the code more readable. It’s the folks who read too much of the books – they go for this…putting it on the new line will be easy to determine the block.
Saw a link to this article on Phil Haacked blog, and really I got astonished to find out that this has been an old story. I mean, maybe something like a design pattern deserve to be the topic of an old and long discussion, but not this one. Developer are strange indeed (including myself).
When working from a laptop with a limited height ie 900 pixels it is a waste of screen real estate to have { on a separate line. Also looks more correct not to have two lines of code ie the function name and the { and the left most position.
20 years ago I recall being told that good coders did not need that extra line break and n00bs did – 🙂
THANK YOU, Mr. Skinner.
I will proudly continue to cuddle my curly-braces and keep my code vertically compact as I’ve been doing since 1993.
This has been weighing down on me since a former co-worker tried to convince me that cuddling my curly-braces was no longer acceptable for AS3.
Cuddler here. I think the colon example is the best – you’d never write
The Ingredients
:
eggs
milk
flour
So it just works within the logic that my brain settles into when programming. I also like that it saves a line of code, and have never found if difficult to find the block of functionality – it begins when the function or loop is declared and continues with the indentation.
I cuddle too. It seems a waste of space to me and is sort of cheating when counting how many lines of code a program has. I mean some languages let you put an entire if/then/else block on one line. Do you count it as one line or half a dozen? I prefer to just put the braces on the same line as the if/then or else. Then again I mainly code in Lua which uses do/end instead of {/}. And of course I keep those on one line.
I really wish we could have someone do the scientific study that puts this question to rest. While what you prefer is subjective, the only real question to ask is what is more readable to the greatest number of people and that is not subjective and could actually be measured.
Imagine an experiment where you present a large number of code snippets randomly formatted into one of the two styles to a large group of programmers and they are asked questions based on those snippets which requires comprehending what the code does. You time how long it takes to answer the question and if they get the answer correct.
With evaluating the data you can put the subjects into one of 3 groups:
1. Those that take significantly longer to comprehend code or have greater number of incorrect answer with the cuddled brace style
2. Those that have no significant difference between the two styles.
3. Those that take significantly longer to comprehend code or have greater number of incorrect answer with the braces on their own line.
If all people fall into group 2 it doesn’t matter. The real question is do a greater percentage of people fall into group 1 or group 3. Whichever group is larger should dictate what style is used, end of story, as the most important aspect is what is the most readable.
Of course, no one has ran the experiments so we have to logically consider which group is most likely the largest between group 1 and group 3.
So to argue that cuddling the brace should be used is to argue that group 3 is larger than group 1. I think that is a very difficult argument to make. It is hard to imagine that a significant number of people will have more difficulty understanding code with the brace on its own line.
I find it much more likely that a greater number of people would fall into group 1 (I for one do fall in group 1).
So unless someone can provide convincing evidence that more people fall into group 3 than group 1 I consider putting braces on their own line as the only choice.
In response to the list / colon argument, think about the following.
Cuddler here. I think the colon example is the best – you’d never write
The Ingredients
:
eggs
…
Syntactically, that makes no sense to me at all. Think about the following. The exact syntax of what you’re trying to show is:
Header:
list
Now, the syntax of a C/C++ if statement is
if ( expression ) statement
which if broken into two lines would become:
if ( expression )
statement
So in the context of the ingredient list argument, it’s incorrect to consider the open brace as the colon, syntactically that role is held by the close parenthesis that follows the expression. This is because the brace is the first token of the controlled statement.
If you were to break the following into two lines:
if ( i > 10 ) i = 10;
would you do it as
if (i > 10) i
= 10;
or:
if ( i > 10 )
i = 10;
Of course, you’d do the second. Do you now see why the colon (last token of the header) corresponds to the close parenthesis, and not the brace, and hence why the brace does not belong on the same line as the if.
Yes, I know that a single controlled statement should always be enclosed in braces, witness the cause of the recent Apple SSL bug for an example of why.
However that does not affect the observation that the open brace is part of the controlled statement, not the controlling portion, and thus does not belong on the same line as the controlling portion.
Please add me to the list of non-cuddlers. I have been writing code in C-based languages since 1981 and I cannot stand to look at cuddled braces. I also hold undergraduate and graduate degrees in computer science; therefore, I formally taught as well as a well-seasoned veteran. The fact is that the curly braces are not extensions of the control structures. Curly braces are in fact a statement known as “compound-statement.” If one views the EBNF for C, one will see that all of the control structures only allow the control of a single statement. To control a group of statements, we use the statement compound-statement denoted by the use of the terminal symbols “{” and “}”. If the common practice is to indent a statement after a control structure, then not only does the open brace belong on a different line because it is part of a statement, it should also be indented (a.k.a. GNU style). This style of indentation preserves the grammar of the language. It also teaches junior coders that the curly braces are not part of the control structures, which is one of the most misunderstood things about the C languages.
If we want to talk about wasted space, the practice of including single statements inside of a curly braces is on the biggest waste of space when using C or a C-derived language. It is done for the most part to over come the dangling-else problem that is part and parcel of these languages. It causes shift-reduce errors when parsing, which requires a compiler writer unless the grammar is re-written slightly to handle this problem. In reality, C is a hack and so are all of the other languages derived from it. Without Bells Labs giving Unix away to universities and government agencies before the AT&T divestiture in 1984, C would have become yet another language in the history books.
A well-written language does not need curly braces or a compound-statement grammatical production. For example, Ada does not have the dangling-else problem. It also has a much cleaner syntax than C. Ada was the first successful language to include generics. It also was the first systems language designed for safety because it was designed to replace a myriad of languages used in the development of safety-critical military systems. Ada programs how much lower levels of bugs than C programs. Java was also designed to be used in embedded systems like Ada, but the Java community over complicated things.
This article does not make enough difference between styles, but mentions shows 2 separate differences at the same time:
– Opening-brace on next the header line versus the next line.
– The ‘else’ keyword on the behind the closing-brace versus on the next line.
These are 2 different things that may be chosen individually, and often they are. Especially in the case of opening-brace on the header-line, where both variants of the ‘else’ statement as seen quite frequently.
Apart from that, this article is also somewhat misleading, because it shows examples that lack proper indenting, which may influence opinions.
Ok and then about my preference here…
First of all, I generally follow the standards of a language or project, like many others mention as well.
However, my personal preference is the last example, known as the Allman style.
Why? Because readability is much more important than easiness of typing.
To be able quickly matching braces on the same line is especially important when code is large for example.
Arguments suggesting that cuddling code styles are so much shorter are also forgetting something, because in many cases we see that everything becomes so compact that it gets harder to read, so that people still insert whitespaces at places where the Allman style would just place the brace.
Here a simple example of a Java code fragment of this:
public class Main {
public static void main(String[] args) {
System.out.println(“Hello, “);
System.out.println(“amazing “);
System.out.println(“world”);
System.out.println(“!”);
/*… additional long code */
}
}
An Allman style example would not need an extra whitespace below the class line for better readability, because it already is readable inherently.
Also note that the first example in the article is NOT the so called K&R style as people sometimes suggest, but rather the so called 1TBS or OTBS style.
The real K&R style did not use braces for single line if/else and it used the same bracing style as Allman for function braces, thus with the opening brace on the next line, while only statement braces inside functions where had the opening brace on the header line.
Ok I have to take back my words about indenting, because it turns out that there is currently a problem with this web page, because my own indentation is also not shown here, until I view the HTML source of this web page.
Please guys fix that.