Sidebar Sidebar
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?

Do you put the curly brace on the same or new line?

  • Same line

    Votes: 42 40.8%

  • New line

    Votes: 61 59.2%
  • Total voters
    103
I am honestly surprised that "new line" is winning! I'm a same line kind of guy all the way!

I've taken my styling queues from apple's own code base, (which in hindsight seems to go back and forth) and from my several books.

So I decided to look through some favored books.

My first fully read programming book, and still my favorite for beginners.
Learn C on the Mac (Mark) -- uses same line!

Programming in Objective-C 2.0 (Kochan) -- uses new line for method's and same line for control structures like for's and if's

Cocoa Programming for Mac OSX (Hillegass) -- uses new lines for methods and same line for control structures.

So once again... still shocked that "new line" is winning. It just seems like so much open wasted space.
 
jared_kipe said:
It just seems like so much open wasted space.
Click to expand...

It's not wasted if it helps readability. Obviously "helping readibility" is subjective. I like the new line style myself, but I'm as surprised as you are to see it winning. The main reason I like it is so I can quickly see if I'm missing a brace. I understand why others prefer the more compact style though.
 
I used to put it on the same line while developing with Netbeans, but thanks Visual Studio now I like to put it in a new line. I think it makes the code more clear.
 
jared_kipe said:
Programming in Objective-C 2.0 (Kochan) -- uses new line for method's and same line for control structures like for's and if's
Click to expand...

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
 
I put them on a separate line, with 'else' on its own line. I find it aids clarity, clarity aids debugging & maintenance and aids keeping customers happy. Which pays my bills:)

I also always use braces, even the 'if' runs a single line when true. eg

Code: 
if (whatever)
{
    Debug.WriteLine("whatever was true.");
}

rather than
Code: 
if(whatever)
        Debug.WriteLine("whatever was true.");

I have seen developers tab in a whole load of lines under the 'if' expecting them all to be executed when the 'if' returns true.

Yes, that's c# code in those code blocks.
 
dmr727 said:
Wait, that's not even a question. emacs? emacs? Do you want some apple juice while you write code? Maybe a pacifier? Even my grandmother thinks emacs is for sissies. :p
Click to expand...

My grandma thinks vi should be dead and buried, as she is. :p

As for the braces, it varies with mood when I'm hacking (testing) things. I prefer that the ending brace easily leads me back to the beginning brace, it has to be on its own line. I'm open to where the open brace is.
 
GorillaPaws said:
It's not wasted if it helps readability. Obviously "helping readibility" is subjective. I like the new line style myself, but I'm as surprised as you are to see it winning. The main reason I like it is so I can quickly see if I'm missing a brace. I understand why others prefer the more compact style though.
Click to expand...

I generally open and close braces at the same time. Meaning I hit open brace, hit the close brace, hit the back arrow, hit return twice and hit the up arrow.

I practically never have a brace problem in my code. Not that I don't have typos and syntax errors from time to time, but braces are not one of them.

EDIT: Oh and I have a Razor Naga mouse and have that little ditty macroed to one of my thumb buttons. :)
 
Viva la new line!

Though I'm glad the conversation has remained civil. I know this could get heated :)
 
Same line. When I started coding I did new line, same line looked weird; now it's the opposite, new line looks clunky to me, even worse with elses. Plus, all those single line braces add up and since we're always fighting for more vertical lines when coding, it means you can see more code without scrolling, generally. But it's funny how in Apple's sample code and default project code, you'll often see a mix even within the same file.
 
I used to put it on a new line, but with indented braces, which I haven't seen here yet. If you're going to put it on a new line, that just seems cleaner to me.

Since I moved from primarily Windows programming to Linux, Ruby, and iPhone, I've come around to same line. I think the primary advantage is that it puts more code in an editor window.

I like lots of code in an editor window. So much so that I've flipped my display sideways, which seems ideal for XCode.

But the *&^%$! OSX menu bar is a LONG way up from the dock!
 
jtara said:
But the *&^%$! OSX menu bar is a LONG way up from the dock!
Click to expand...

Sorry, not to derail but I don't understand the relationship in this statement.

You're a programmer. Your hands are on the Keyboard where (if Universal Access is enabled) you can get to the Menu Bar and Dock with:

• Control-F1 Toggle enable/disable Universal Access
• Control-F2 Move focus to the menu bar
• Control-F8 Move focus to the status menus
• Control-F3 Move Focus to the Dock

Cursor keys and alpha characters to skip around within and Escape to return to previous focus state.
 
New line, nearly always.

Why:

Code: 
- (void)establishBindingTo:(id)foo
{
    //a whole bunch of other code
    if (someIvar.someBool == YES)
    {
        [someIvar bind:@"attribute"
              toObject:foo
               keyPath:@"key.path"
           withOptions:[NSDictionary dictionaryWithObjectsAndKeys:
                        [NSNumber numberWithBool:YES], NSSomeBindingOption1
                        [NSNumber numberWithBool:YES], NSSomeOtherBindOption
                        [NSNumber numberWithBool:YES], NSYouGetTheIdea,
                        nil]];
    }
}
I've already got multi-line method calls, and I don't want to have to keep track of what the current indent is for. I want a nice loud "HEY, YOU'RE IN A MORE LOCAL SCOPE. BETTER CHECK WHY BEFORE MAKING CHANGES!" A brace on an otherwise empty line serves that purpose excellently.

What I'd really like is if the IDE drew a dotted or dashed vertical line between opening and closing braces. I know some IDE's will let you do this, but what I want is for the dot/dash pattern to be different between different levels of braces: ie:

Code: 
{
`    {
`    :    {
`    :    |
`    :
`    :    |
`    :
`    :    |
`    :    }
`    }
}
Obviously rendered better than that, and not in ASCII art. The ribbon in Xcode is a good start, but you still have to trace your eyes, cursor, or worst, your insertion point horizontally to find the start or end of the block, with no guide. This way, you can look at the pattern at the top (or bottom, which is how I'd use it more) and just let your eyes scan for the same pattern higher up the page, or follow the line up with it as a guide.
 
Without any local code guidelines I use the style used in the language reference and/or standard library. e.g., same line for Java, new line for C#.

I don't think one style is more readable than the other. I do, however, agree that conditional statements with a one line content should always have braces except if the language support "reversed" if statements such as Perl or Ruby.
 
Can't vote here, I alternate between them depending on the programming language and any project-related coding conventions.

Unless otherwise specified through coding conventions (from employer, project leader, customer, whatever), I use new line for C and same line for Java to mention two cases.
 
I primarily code in Java and the standards say to place it on the same line. My IDE also will autoreformat the code and by default puts it on the same line.

Plus if anybody gets into a nerd argument about it, I pretty much win be default because I just say I'm using the standard... :p I try to code to the standards as much as possible actually...
 
I've done new line my entire career, but inevitably, there's always someone who burrows through the code and wants it changed the other way.

The only time I find same line curly braces to be useful are when using the IDE editors or really large bodies of code with lot's of nested if's. Then it starts to fall so far off the screen, it becomes a PITA to use vi to look through the file.
 
IBrown said:
I put them on a separate line, with 'else' on its own line. I find it aids clarity, clarity aids debugging & maintenance and aids keeping customers happy. Which pays my bills:)

I also always use braces, even the 'if' runs a single line when true. eg

Code: 
if (whatever)
{
    Debug.WriteLine("whatever was true.");
}

rather than
Code: 
if(whatever)
        Debug.WriteLine("whatever was true.");

I have seen developers tab in a whole load of lines under the 'if' expecting them all to be executed when the 'if' returns true.

Yes, that's c# code in those code blocks.
Click to expand...

I completely agree with you. It only takes once to get bitten by bug where some developer thinks the if statement works for all statements that are indented to always put braces around it.

If you're truly worried about space and it's a single line I have no issue with:

Code: 
if (whatever) {Debug.WriteLine("whatever was true.");}

or

Code: 
if (whatever) Debug.WriteLine("whatever was true.");

IMHO, in both of those statements it's very clear what is effected by the conditional.
 
One of the reasons I always put brackets after an if statement is so that you could always insert a line of code and not f anything up.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back