Mac Coding Style

butcher

macrumors newbie
Original poster
Apr 11, 2005
2
0
Just wondering, which style do you use?


Code:
if(condition){

// do something

}

or

if(condition)
{

//do something

}
 

fcomstoc

macrumors regular
Sep 12, 2013
106
59
Las Vegas, NV
When programming in any programming language (C++, C#, PHP, Java, etc.) I have always used

Code:
if(condition)
{
//stuff
}
I think it is better for organization and hierarchy.

but when I am writing css I always use same line e.g.
Code:
if(condition){
//stuff
}
because it is the dreamweaver default; although I have never really liked this style. It does take up less space though.
 
Last edited:

lee1210

macrumors 68040
Jan 10, 2005
3,182
1
Dallas, TX
This is all preference. The code formatter at work puts the open brace on the line with the construct instead of a new line, and that's what I've done for a long time.

-Lee
 

larswik

macrumors 68000
Sep 8, 2006
1,552
11
Code:
if( true ){
  //do something amazing
}
This is what I ended up doing when I started. For me it is 1 less line of code this way.
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
8,661
4,200
Here's a style that always pisses me off:

Code:
if (condition) {
  // ... some code...
}
else {
  // ... some other code
}
Personally, I do:

Code:
if (condition) {
  // ... some code...
} else {
  // ... some other code...
}
I find putting the opening brace on a new line acceptable, but if you're going to put open braces on the preceding line, put the else with the closing brace! I just find it awkward and it slows down how quickly I can understand code if it's written the first way.

When I first started, I put braces on their own line. I started changing to putting braces not on their own line years ago, but I didn't really become consistent about it until learning Python last year, where I realized how consistently Python is easy to read. And I realized that where you put line breaks has a huge part to do with it. So I try to pretend all the code I write is in Python, even though I have to deal with braces.
 

jeremysteele

macrumors 6502
Jul 13, 2011
415
151
Code:
if(condition) {
}
else {
}
That's how I do it.

Honestly though - I think indentation is more important than the dang brackets. People put way too much emphasis on bracket styles.
 

larswik

macrumors 68000
Sep 8, 2006
1,552
11
Code:
if(condition) {
}
else {
}
That's how I do it.

Honestly though - I think indentation is more important than the dang brackets. People put way too much emphasis on bracket styles.
Very True. But I remember when I started this was also one of my questions. You unsure of yourself as you are starting out.
 

ohbrilliance

macrumors 6502a
May 15, 2007
943
217
Melbourne, Australia
I go with
Code:
if( true ){
  //do something amazing
}
and use braces in all cases, even if there is only a single statement. This aids in readability, is less error-prone and avoids the need to add and remove braces should logging calls be added.

I declare functions as
Code:
void doSomething()
{
  //do something amazing
}
 

superscape

macrumors 6502a
Feb 12, 2008
930
218
East Riding of Yorkshire, UK
Crikey! It looks like I'm the only one who does:

Code:
if (condition) 
{
  // ... some code...
} 
else 
{
  // ... some other code...
}
I guess it maybe comes from when I started out many, many years ago with on AppleScript where the syntax is enforced as:

Code:
if (a is 1) then
	--do stuff
else
	--do something else
end if
...so I just chose a syntax that was as close to what I was used to as possible.

I don't see that it really matters, although I think for the sake of tidiness it's best to choose a style that works for you (or your team) and stick to it.
 

whooleytoo

macrumors 604
Aug 2, 2002
6,569
641
Cork, Ireland.
This is all preference. The code formatter at work puts the open brace on the line with the construct instead of a new line, and that's what I've done for a long time.

-Lee
Not always.. there are a few (marginal) cases where the brace location can have a functional impact (see here).

It's mostly preference alright though. There are some small benefits to either approach. The 'brace on same line' format uses fewer vertical lines meaning you can view more code on a screen at the same time, which is useful. The 'brace on new line' approach is more spaced out, and IMO more readable - particularly when reading code you're reading someone else's code - just as a big monolithic paragraph is less readable than several short, discrete paragraphs.

Personally, the 'brace on same line' approach bugs me (far more than it should!!), as in my head it's putting things together which shouldn't be. Just as it would annoy me (too much) if someone typed:

Hi whooleytoo. Good
day.
How are you? Good
night.

instead of:

Hi whooleytoo.
Good day.
How are you?
Good night.
 

Cromulent

macrumors 603
Oct 2, 2006
6,039
36
The Land of Hope and Glory
I use Allman (aka BSD style) style for braces. I find it much easier to read code when braces are on separate lines. I even use full braces when you don't have to (such as a single statement after an if clause).

Vertical space is not such an issue any more with modern monitors. On the other hand I always try and ensure my code fits in to a column width of 80 characters so that I can have multiple source code files open at the same time.
 

mfram

macrumors 65816
Jan 23, 2010
1,061
141
San Diego, CA USA
Always...

Code:
if (blah == 0)
{
    ;
}
else if (blah == 1)
{
    ;
}
else
{
    ;
}
Looks cleaner to me. And it allows braces to match up. I think putting the braces on the same lines 'compresses' the code too much and makes it harder to read. I like the code being a little more 'spread-out'.
 

firewood

macrumors 604
Jul 29, 2003
7,754
1,013
Silicon Valley
I code in Terminal windows as well as Xcode on an MBA 11. I even do some minor coding from my iPad to a virtual remote desktop. Therefore I prefer the style that lets me see the most code logic without looking or scrolling up and down. I use added whitespace to separate out clear functional differences in a method, not just every random statement.

People who use big monitors can stretch the code out vertically for a little better readability. But then they're stuck at their desk with the big monitor(s), while I can code out on the deck in nice weather.
 

iMacFarlane

macrumors 65816
Apr 5, 2012
1,123
23
Adrift in a sea of possibilities
Code:
if (condition)
{
    ;
}
else
{
    ;
}
Crikey! It looks like I'm the only one who does:

Code:
if (condition) 
{
  // ... some code...
} 
else 
{
  // ... some other code...
}
I guess it maybe comes from when I started out many, many years ago with on AppleScript where the syntax is enforced as:

Code:
if (a is 1) then
	--do stuff
else
	--do something else
end if
...so I just chose a syntax that was as close to what I was used to as possible.

I don't see that it really matters, although I think for the sake of tidiness it's best to choose a style that works for you (or your team) and stick to it.
Not always.. there are a few (marginal) cases where the brace location can have a functional impact (see here).

It's mostly preference alright though. There are some small benefits to either approach. The 'brace on same line' format uses fewer vertical lines meaning you can view more code on a screen at the same time, which is useful. The 'brace on new line' approach is more spaced out, and IMO more readable - particularly when reading code you're reading someone else's code - just as a big monolithic paragraph is less readable than several short, discrete paragraphs.

Personally, the 'brace on same line' approach bugs me (far more than it should!!), as in my head it's putting things together which shouldn't be. Just as it would annoy me (too much) if someone typed:

Hi whooleytoo. Good
day.
How are you? Good
night.

instead of:

Hi whooleytoo.
Good day.
How are you?
Good night.
Always...

Code:
if (blah == 0)
{
    ;
}
else if (blah == 1)
{
    ;
}
else
{
    ;
}
Looks cleaner to me. And it allows braces to match up. I think putting the braces on the same lines 'compresses' the code too much and makes it harder to read. I like the code being a little more 'spread-out'.
I am totally with you guys. It's a small annoyance that XCode defaults to the { on the same line as the construct, but I take the time to space everything out while I'm thinking about how I'm going to tackle whatever problem I'm working on. Unless there's a way to change that behavior . . .
 

MeFromHere

macrumors 6502
Oct 11, 2012
468
16
Crikey! It looks like I'm the only one who does:

Code:
if (condition) 
{
  // ... some code...
} 
else 
{
  // ... some other code...
}
I guess it maybe comes from when I started out many, many years ago with on AppleScript where the syntax is enforced as:

Code:
if (a is 1) then
	--do stuff
else
	--do something else
end if
...so I just chose a syntax that was as close to what I was used to as possible.
...
No, you're not the only one. I know a lot of people, including myself, who prefer to put matching braces in the same column.

The AppleScript syntax (which has a lot in common with Ada and similar languages) seems much more readable to me. C-like languages only have one grouping mechanism:
Code:
 { ... }
which is used for many different things (bad) and is optional (bad).

In contrast, the AppleScript way,
Code:
if
    ...
end if

tell
    ...
end tell
removes much of the inconsistency. "if" ALWAYS needs a matching "end if", and "end if" needs "if". "end tell" needs a matching "tell". In C, "}" needs a matching "{", but you have no idea what the "{" will belong to until you find it.
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
8,661
4,200
No, you're not the only one. I know a lot of people, including myself, who prefer to put matching braces in the same column.

The AppleScript syntax (which has a lot in common with Ada and similar languages) seems much more readable to me. C-like languages only have one grouping mechanism:
Code:
 { ... }
which is used for many different things (bad) and is optional (bad).

In contrast, the AppleScript way,
Code:
if
    ...
end if

tell
    ...
end tell
removes much of the inconsistency. "if" ALWAYS needs a matching "end if", and "end if" needs "if". "end tell" needs a matching "tell". In C, "}" needs a matching "{", but you have no idea what the "{" will belong to until you find it.
Or there's the far supperior Python syntax. A block of code will be indented. When the indent ends, you're out of that block of code.
 

jeremysteele

macrumors 6502
Jul 13, 2011
415
151
Very True. But I remember when I started this was also one of my questions. You unsure of yourself as you are starting out.
True. New dev's dont realize consistency is truly what matters.

What ticks me off is when I see this kind of inconsistent crap :mad:

Code:
function (roof,
floor,
cow) {
   printit();
}

function (roof) { print("zooo"); }
I hate to go British but.... every time I see that I think: bloody hell - pick a style!!
 

subsonix

macrumors 68040
Feb 2, 2008
3,551
79
Or there's the far supperior Python syntax. A block of code will be indented. When the indent ends, you're out of that block of code.
It's ok until you or someone else accidentally change intentation during an edit and change the meaning of the code, if you are lucky it creates an error and you notice it. Since there's no compilation, it will also always be a runtime error.
 

MEJHarrison

macrumors 65816
Feb 2, 2009
1,425
1,394
I watched a training video recently for work. The guy was saying that if they had only picked a style when they invented C and mandated it, they would have saved us centuries in man-hours from people not having this discussion. :p
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
8,661
4,200
It's ok until you or someone else accidentally change intentation during an edit and change the meaning of the code, if you are lucky it creates an error and you notice it. Since there's no compilation, it will also always be a runtime error.
You can compile Python code. The interpreter is capable of either interpreting your code as you wrote it or as Python byte code (that's what the .pyc files you'll sometimes see are. Sometimes the interpreter will just compile the file when you tell it to run, then it'll run that compiled file).

As for mistakes being caught, you should be using PyUnit and writing unit tests to catch stuff, and running those unit tests before commiting code to the repository. At the very least, you should be running diff before committing and seeing the mistake and removing it before committing (so many times I almost forget to remove debug messages...)
 

Similar threads

  • view60
1
Replies
1
Views
183
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.