I do the same thing with the else. Every brace gets its own line. ;D
[quote]everyone probably agrees that an “unblocked” if should look like this:
[/quote]
No, i agree that everyone who uses “unblocked” ifs should be shot anyway… ;D
quickly cleans up code
That’s some harsh words over personal preference…
I personally feel unblocked one liner ifs makes
things more readable.
Feel free to flame me now…
;D
I said it before in this thread, and I’ll say it again. I really don’t think it matters one way or another, as long as you are consistent and all who contibute code use the same style.
YOU FOOL!
;D
Actual code from my friends C++ project… this is how he writes it, I have not added any line breaks:
// removed beginning of function...
hRes = m_pDevice->QueryInterface(
__uuidof( IMyGraphics ),
(void**)&pGFX
);
if( !SUCCEEDED( hRes ) )
throw _com_error( hRes );
// <removed real comment>
m_pGFX = pGFX;
hRes = pGFX->Release();
if( !SUCCEEDED( hRes ) )
throw _com_error( hRes );
}
void
MyDevice::FreeResources(
void
)
{
}
void
MyDevice::CollectInfo(
void
)
{
m_DeviceInfo = m_pDevice->QueryInformation();
m_StreamInfo = m_pStream->QueryInformation();
}
oh yeah - if he had a multi-line ‘if’ it would have the braces lined up - the one part where I agree with him 
Could you force yourself to conform to this style? - I can’t.
I started out using #2, and for a long time I detested reading #1 code. But I switched to #1 because most of my coworkers and the java stander used it. Now I don’t realy have a personal preferance.
It’s a question about habit, not what is best.
I like #2, and is what I use at my job. As for wasted “space”, folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine. Or get a used, cheap one from someone upgrading to dual LCD’s or something. Just get one of those and maximize your IDE and any arguments about “wasting vertical space” should be alleviated. I’ve never “bought” the whole “wasted space” argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college). I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I’m just odd.
[quote]I like #2, and is what I use at my job. As for wasted “space”, folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine. Or get a used, cheap one from someone upgrading to dual LCD’s or something. Just get one of those and maximize your IDE and any arguments about “wasting vertical space” should be alleviated. I’ve never “bought” the whole “wasted space” argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college). I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I’m just odd.
[/quote]
Mongo, I completely agree with you. #1 sucks. 
[quote] I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1. But maybe I’m just odd.
[/quote]
Absolutely. The blocks stick out plain as day. With #1 if there’s any amount of nesting of blocks I have to stop and follow it fairly carefully, especially if I didn’t write the code. Most people who are fans of #1 are usually fans of no extra linefeeds whatsogoddamnever too!
But now that most IDEs can reformat code in seconds, it doesn’t bother me so much.
Oh boys. Using 1 is much better you know, at least much better than read C++ code especially open source.
Best is to have IDE that could reformat code to your style and then back to original. In most cases you are responsible for the class file and you do every modification yourself.
public void meth(){
somedeclaration;
int c4=(int) log(c6);
for(int c7=0;c7<12366;c7++){
callsomethingweird(c4);
}
}
my programs look better after dissasambly, but I hardly do mistake. I lost most time becouse I didn’t believe there wasn’t mistake. And was lazy to use out.println();
come on people, #1 is the way to go…#2 reminds me of a double negative.
public void foo()
{
//blah
}
is readable, but the braces do not have to be lined up because in
public void foo(){
//blah
}
the exact start of the function already lines up with the exact end, and doesnt this just make sense? i’m sure you all realize this but it’s more symmetrical to have ONE start line and ONE end line.
symbols such as { && ||, etc really shouldnt start their own lines, just as the words “including”, “and”, and “or” do not properly begin sentences in English.
thats why I prefer
public void foo(args){
if(long boolean statement one &&
long boolean statement two){
}
else if(boolean){
}
}
over this monstrosity:
public void foo(args)
{
if(long boolean statement one
&& long boolean statement two)
{
}
else if(boolean)
{
}
}
Which brings us round to another pathetically silly point:
spaces and lining things up
This above:
public void foo(args){
if(long boolean statement one &&
long boolean statement two){
}
else if(boolean){
}
}
should be written
public void foo(args) {
if (long boolean statement one &&
long boolean statement two) {
} else if (boolean) {
}
}
And when I say should I mean, thats the way I do it 
Kev
[quote] And when I say should I mean, thats the way I do it
[/quote]
Me too, that ought to be enough people to make it a fact, ehh?
Oh, no. When wrapping a single statement over multiple lines, you have to indent it twice. Or even better, avoid it! Chances are you probably should break that statement up into smaller chunks anyway.
And the boolean condition definitely goes on the second line, to improve readability. You don’t say “chips and, peas” rather than “chips, and peas” do you? ;D
I wouldn’t put a comma in either ;D
Kev
:
No, neither would I - it’s only there for emphasis…
[quote]come on people, #1 is the way to go…#2 reminds me of a double negative.
…
the exact start of the function already lines up with the exact end, and doesnt this just make sense? i’m sure you all realize this but it’s more symmetrical to have ONE start line and ONE end line.
[/quote]
Sorry, I’m bored; waiting for a server to crash, so I can view the logfiles (I’ve just turned full debugging on). So, with nothing better to do… (don’t take this too seriously)
IIRC this has already been covered. Braces ARE NOTHIGN TO DO WITH FUNCTIONS (in the general case), they merely allow multi-line statements.
Hence, the “start line” as you put it is, in fact, the opening brace NOT the function.
Grammatically speaking, they actually DO start their own lines, because they are phrase-starters, and we’re talking about phrases, NOT sentences.
But because of early drop-out, you cannot tell at a glance down the LHS which lines will execute. This is important because speed-readers read in columns, and they have to read the LHS anyway to see the end-braces (irrespective of style).
Research into how musicians sight-read has concluded (rather unexcitingly :)) that the main difference between “excellent” and “poor” sight-readers was that the really good ones scanned in an almost monotonic line across the page, NEVER going backwards. Novices darted forwards, backwards, etc, and just couldn’t keep up with the music (which of course has to move forwards monotonically too).
The research was done using eye-tracking, and plotting graphs on the music of where the musician was looking over time. Interesting stuff :).
Aha. So that’s why I always botched my sight reading. Then again, sight reading in competition is bogus, as far as I can see.
[quote]i’m sure you all realize this but it’s more symmetrical to have ONE start line and ONE end line.
[/quote]
No, visually you break the symmetry of the braces - THEY wrap the block, not the method declaration before them
[quote]symbols such as { && ||, etc really shouldnt start their own lines, just as the words “including”, “and”, and “or” do not properly begin sentences in English.
thats why I prefer
public void foo(args){
if(long boolean statement one &&
long boolean statement two){
}
else if(boolean){
}
}
over this monstrosity:
public void foo(args)
{
if(long boolean statement one
&& long boolean statement two)
{
}
else if(boolean)
{
}
}
[/quote]
The thing is the beginning of the line is not always equivalent to the beginning of a sentence, and there are other reason to but &&, || at the beginning of the line instead of the end.
Basically they can get ‘lost’ off the end of the line when you are reading code… the end of the line is generally more jagged, and it could be of the screen entirely. Placing the && || at the beginning, nicely aligned shows clearly in a more localised spot how the conditions are logically evaluated.
e.g.
if( long boolean statement one
&& short bool
|| long boolean statement two
)
{
}