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 Coding Style
- Thread starter butcher
- Start date
- Sort by reaction score
When programming in any programming language (C++, C#, PHP, Java, etc.) I have always used
I think it is better for organization and hierarchy.
but when I am writing css I always use same line e.g.
because it is the dreamweaver default; although I have never really liked this style. It does take up less space though.
Code:
if(condition)
{
//stuff
}but when I am writing css I always use same line e.g.
Code:
if(condition){
//stuff
}
Last edited:
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
-Lee
Here's a style that always pisses me off:
Personally, I do:
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.
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.
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.
I go with
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:
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
}
Crikey! It looks like I'm the only one who does:
I guess it maybe comes from when I started out many, many years ago with on AppleScript where the syntax is enforced as:
...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.
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.
Why? It's more consistent with the if. Each clause start on it's own line, has the same indentation and margins, is easier to edit by line.
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.
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.
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.
Always...
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'.
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 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.
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.
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 . . .
I try to follow RobotsAndPencil's Style Guide:
Code:
if (!goodCondition) return;
if (condition == YES) {
// do stuff
} else {
// do other stuff
}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:
{ ... }In contrast, the AppleScript way,
Code:
if
...
end if
tell
...
end tellOr 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.
True. New dev's dont realize consistency is truly what matters.
What ticks me off is when I see this kind of inconsistent crap
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!!
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.
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.
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...)
Pretty much what I do. I hate brackets on their own line. Although I tend to not do brackletless if statements. They're bugs waiting to happen. Not as much if they're on one line, but I try to avoid them.