17 Jan, 2010, Skol wrote in the 1st comment:
Votes: 0
Hey, quick question while we're on correctness:
Curly braces with regards to indentation and style…

void do_something() {
// blah
}

vs
void do_somethingelse()
{
// blah blah
}


Reason I ask is that in C I've always used the latter method, but in PHP and Perl I often see the first method. I got used to the second as it was easier for me to see the start/end of braces without having to comment (due to indentation).
17 Jan, 2010, Twisol wrote in the 2nd comment:
Votes: 0
See this page. It doesn't really matter, but some languages seem to have certain styles most commonly used. I prefer the Allman style (braces get their own line, content indented) myself. I can't understand why some people like the Whitesmiths style, but it seems like a lot of the MUSHclient source code uses it.
17 Jan, 2010, Mudder wrote in the 3rd comment:
Votes: 0
Lyanic said:
David Haley said:
Mudder said:
People here aren't customer service nerds, they're computer nerds. :wink:

Not sure what you're implying here.

He's implying that your customer service skills suck, computer nerd.


What he said.

David Haley said:
Lyanic said:
He's implying that your customer service skills suck, computer nerd.

Not sure why that is remotely relevant, but eh. Ok. (And people should speak for themselves, not others, when they talk about being socially inept…)

It was mostly a joke. Computer guys are notorious for having very bad people skills. Of course it is simply a generalization but that is why I find it funny. See?

Lyanic said:
Also, where do you keep disappearing to, Mudder?

Being back in the States I have a lot of friends that I have largely ignored for the year I was overseas. (Because I was overseas…) So I have been hanging out with as much as I can, driving way more than I ever want to again, and preparing to return back to my college town and finish that up. How irritating that all of my friends live at least 48 minutes away, in all different directions. Lame.
17 Jan, 2010, kiasyn wrote in the 4th comment:
Votes: 0
Skol said:
Hey, quick question while we're on correctness:
Curly braces with regards to indentation and style…

void do_something() {
// blah
}

vs
void do_somethingelse()
{
// blah blah
}


Reason I ask is that in C I've always used the latter method, but in PHP and Perl I often see the first method. I got used to the second as it was easier for me to see the start/end of braces without having to comment (due to indentation).


I actually started off doing the latter originally, and hated the former. But then I used an IDE that auto formatted it to the former, and got used to it and now I use that. It has given me some interesting bugs though, forgetting i put a { on the same line as an if ;)
17 Jan, 2010, elanthis wrote in the 5th comment:
Votes: 0
You might as well ask whether people prefer blondes or brunettes. :/
17 Jan, 2010, Idealiad wrote in the 6th comment:
Votes: 0
brunettes.

But wouldn't it be better (I know, subjective, etcetera) from a style standpoint to do

void do_something() {
….
}


So you see that indentation which delimits the code block?
17 Jan, 2010, Twisol wrote in the 7th comment:
Votes: 0
Perhaps. If you don't forget the braces. That's one of the other styles on the wiki page I linked, too, and I don't like it, either: it feels very strange to me.

EDIT: blondes and brunettes.
17 Jan, 2010, elanthis wrote in the 8th comment:
Votes: 0
Smart-asses. Fine. Redheads and Python (no curly braces at all). :p
17 Jan, 2010, Bojack wrote in the 9th comment:
Votes: 0
Some people like myself use the braces on a seperate line for 2 reasons: 1. you can see where you missed a brace. 2. You know which one to close off just by scrolling up and down
17 Jan, 2010, Confuto wrote in the 10th comment:
Votes: 0
elanthis said:
Smart-asses. Fine. Redheads and Python (no curly braces at all). :p

+1 to both, I guess. >_>
17 Jan, 2010, David Haley wrote in the 11th comment:
Votes: 0
The main advice I would give is to always use braces even if you have just one line, then there is no issue of remembering or forgetting them.

After quite some time writing quite a lot of Python at work, I find that not having any block delimiters whatsoever is actually not so nice because with large functions it means having to bounce around to figure things out. If anything, the block-end gives the text editor something to match visually (or press a key and go to its peer). And don't tell me that functions should be broken out blablabla because sometimes you can't (numeric/scientific code in particular) and sometimes you didn't write it but still have to read it.

Mudder said:
Computer guys are notorious for having very bad people skills.

I feel sorry for you to have been so unlucky in the computer people you've worked with. :wink:
17 Jan, 2010, Tyche wrote in the 12th comment:
Votes: 0
+1 on redheads.
As far as indenting I don't care much. I do tend to use K&R style in my code. If it's not my project, I just adopt the style of those that went before (unless they don't care either).
It's so trivial to reformat most source code, I don't spend much time worrying about it.
17 Jan, 2010, elanthis wrote in the 13th comment:
Votes: 0
Quote
After quite some time writing quite a lot of Python at work,


I actually hate using Python for anything more than smaller, self-contained modules. Indentation was not a problem, though. Then again, I use a decent editor. A Python-aware editor (or an editor that can be scripted to become Python-aware) can auto-navigate to the beginning or end of blocks just as easily as they can in C/C++; it just has to scan for changes in indentation level instead of curly braces (which is harder than you might think at first when you take into consideration macros and strings).

Boo is a great language that has the syntactical beauty of Python with the large-architecture-friendliness of static-typing and high-performance runtime, worth checking out.

Quote
If it's not my project, I just adopt the style of those that went before


That is critical, IMO. No matter what your preferences on code formatting are, there is nothing about one's personal format preference that makes the benefits of using it in a project outweigh the costs of having inconsistent formatting all over the place.
17 Jan, 2010, David Haley wrote in the 14th comment:
Votes: 0
elanthis said:
A Python-aware editor (or an editor that can be scripted to become Python-aware) can auto-navigate to the beginning or end of blocks just as easily as they can in C/C++; it just has to scan for changes in indentation level instead of curly braces (which is harder than you might think at first when you take into consideration macros and strings).

It's not just navigation, but visual recognition as well. Change in indentation is easy to see, but it's harder to distinguish different shiftwidths. You need to start counting spaces. Braces are clear markers.

elanthis said:
Boo is a great language that has the syntactical beauty of Python with the large-architecture-friendliness of static-typing and high-performance runtime, worth checking out.

As you are probably well aware when it comes to work environments, these decisions are often out of our hands by this point. :wink:
17 Jan, 2010, quixadhal wrote in the 15th comment:
Votes: 0
David Haley said:
It's not just navigation, but visual recognition as well. Change in indentation is easy to see, but it's harder to distinguish different shiftwidths. You need to start counting spaces. Braces are clear markers.


Poppycock.

You don't need to count anything. If you write clear code, you know what to expect as you're scanning it. If your functions are so enormously long that you can't keep track of the indent level at a glance, you need to put down the keyboard and go bash your head against the wall until you see a way to refactor it.

if(a) {
b();
for(i = 0; i < 20; i++) {
c();
}
d();
} else {
e();
}

if(a)
b()
for(i = 0; i < 20; i++)
c()
d()
else
e()

I don't see any added value to the braces. Now, if you want to write unreadable and unmaintainable code that doesn't indent cleanly, sure…
if(a) { b(); for(i = 0; i < 20; i++) { c(); } d(); } else { e(); }

Have fun with that.
17 Jan, 2010, Sandi wrote in the 16th comment:
Votes: 0
I agree there's no added value to the braces, and I never use them in mushcode. But in your first example, quix, I find it hard to match them visually.

And I was sorta surprised to find, thanks to mushcode, that after an initial double take, I could read your third example. But, there's gotta be some wasted brainpower there.

In C, I use the Allman style, with tabs = 4.
17 Jan, 2010, Tyche wrote in the 17th comment:
Votes: 0
quixadhal said:
I don't see any added value to the braces. Now, if you want to write unreadable and unmaintainable code that doesn't indent cleanly, sure…
if(a) { b(); for(i = 0; i < 20; i++) { c(); } d(); } else { e(); }

Have fun with that.


The problem is all your examples are unreadable and unmaintainable, but it ain't because of indenting or placement of braces.
if(a_fooble) { betray_bars(); for(i = 0; i < 20; i++) corterize_que(); dewinchelate_feebix(); } else error();


There. Much better. :-)
17 Jan, 2010, Barm wrote in the 18th comment:
Votes: 0
I prefer Whitesmith's and have always wondered why it's not more popular. It's the easiest to parse visually as the entire block is indented equally in relation to its control statement. Plus, if the goal is to indent logic blocks why treat the 'start of block' and 'end of block' tokens as external elements?
17 Jan, 2010, Skol wrote in the 19th comment:
Votes: 0
Thanks! Great link btw Twisol, thanks much.

I find that I vary depending on previous style as well, but usually go Allman.
Although, often in PHP I'll go completely inline<?php and_go().like->this?> if I'm writing mixed html/php (I feel dirty too).
17 Jan, 2010, David Haley wrote in the 20th comment:
Votes: 0
quixadhal said:
If your functions are so enormously long that you can't keep track of the indent level at a glance, you need to put down the keyboard and go bash your head against the wall until you see a way to refactor it.

You must have missed the part where I said: "And don't tell me that functions should be broken out blablabla because sometimes you can't (numeric/scientific code in particular) and sometimes you didn't write it but still have to read it. " :wink:

Anyhow, your example is pretty trivial; when I spoke about counting I thought it was clearly implying several levels of indentation; when code jumps two vs. three at a time while spanning many vertical lines, it's hard to keep exact track and requires that much more processing.

One should not conflate "you can do it" with "you can do it more easily". This is what Sandi is speaking to with this comment:
Sandi said:
And I was sorta surprised to find, thanks to mushcode, that after an initial double take, I could read your third example. But, there's gotta be some wasted brainpower there.


Even so, a lot of this is obviously habit.
0.0/37