views:

213

answers:

7

this:

public void foo() {
    for (int i = 0; i < rows; i++)     // <--- no brace!
        for (j = 0; j < columns; j++)   // <--- no brace! 
            table[i][j] = new Blabla(i, j);
    other();
}

or this:

public void foo() {
    for (int i = 0; i < rows; i++) {
        for (j = 0; j < columns; j++) {
            table[i][j] = new Blabla(i ,j);
        }
    }
    other();
}
A: 

Are you referring to the space before the bracket on the for loop?

I'd personally say no space there, but it doesn't keep me awake at night. The most important thing is to be consistent.

Noel M
I'd rather say he's referring to the lack of brackets in the first example.
nos
@nos: That wasn't visible until somebody edited the post.
Matti Virkkunen
Hmm the question has changed quite a bit from when I answered...
Noel M
yes, sorry, is my first post
enriqueM
+10  A: 

It's better to include the braces as otherwise someone might add an extra line thinking it will be inside the loop, but actually it will be run only once after the loop completes.

public void foo() {
    for (int i = 0; i < rows; i++)
        for(j = 0; j < columns; j++)
            table[i][j] = new Blabla(i, j);
            count++;                // <--- potential bug!
    other();
}
Mark Byers
I always find this argument very odd. How come aren't Python programmers running into this all the time? I'm sure that even people who use languages where indentation isn't part of the code rely on it to read the code.
Matti Virkkunen
@Matti Virkkunen: Because Python does what you expect.
Mark Byers
@Mark: Hm, I seem to have my brain on backwards today... sorry for that.
Matti Virkkunen
This "someone might think" fear is boogie-man-around-the-corner logic. The code should be written however it is most readable and clear. The code above is flawed not by the lack of braces but by poor indentation.
Peter DeWeese
+1 "defensive" programming
dogbane
I wasted days on a spurious semicolon. Since then, I've always put braces in, and have envied Python since shortly after flicking through a book on it in George's.
Tom Hawtin - tackline
*"The code above is flawed [...] by poor indentation."* Yes. But it happens.
dmckee
+1  A: 

I would always include the curlies unless it's only one statement in the body of the for (or any other statement like if/while) and you can see that it's a shortened style. If you leave the curlies out in your case, you could quite easily change the behaviour of the method by simply adding one method call at the wrong place, because you think it will land in the body of the for.

Femaref
+1  A: 

The second one is more readable.

I can deal with omitting braces from a single statement, but nesting that is too much.

Matti Virkkunen
+2  A: 

This is a matter of taste. Personally I always use brackets, because I like it and I has been bitten by the "add another statement which ends up outside the block because it wasn't delimited".

I've grown more lenient, because we now has as a policy to have Eclipse reformat all sourcefiles every time they are saved (called Save Actions), so the indentation is always right and doesn't trick you to think statements are inside a block when they are outside. Highly recommended.

Thorbjørn Ravn Andersen
A: 

for very simple an clear code like that, no brace.

if someone comes and adds something in the wrong scope, paying no attention to the surrouding code, giving no second look at the new code, I wouldn't have him touch my code ever again.

irreputable
*"my code"*... just LOL. Do you realize that 1. you might work in a team (ever heard of collective code ownership?) 2. that you won't be maintaining *"your"* code for ever? Make it [Jimmy proof](http://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined/2353436#2353436).
Pascal Thivent
I agree with @irreputable. An idiot will break code with or without braces regardless because that is what they do. I'd rather design for what is needed than include unnecessary ceremony that can be added later when it is actually useful. Thats what this comes down to: people who include extra ceremony out of fear and people who do not.
Peter DeWeese
@Peter If you don't make your code mistake proof, the mistake will happen. I thus consider people designing non mistake proof code as idiots too, especially if they do it deliberately. Conclude yourself.
Pascal Thivent
fortunately I can fire idiots instead of babysitting them.
irreputable
Brackets don't make the code mistake-proof. That is the flaw in the logic presented. Trailing brackets have a greater readability and modification risk than implied brackets, and yet I can live with those too if they are standardized in a project along with an expectation that proper indentation will mitigate the risk. Eclipse and other tools can auto-format to encourage proper indentation, or tools attached to source control can enforce it further. Mistakes will occur despite our arrogance that we can prevent them, and they can be fixed. Redundant ceremony is always a burden.
Peter DeWeese
@Pascal, I think you should elaborate on "mistake proof"-code. Everybody can make mistakes, so it cannot be THAT interpretation.
Thorbjørn Ravn Andersen
@Thorbjørn That's my point: people make mistakes. So why choosing the most "fragile" solution when using brackets does remove a potential source of mistake. Sure we have IDEs, the code should be tested, etc but I had to work with all kind of developers and to my experience, sh** happens and I've learned that trying to minimize potential causes of mistakes does pay. In this case, using brackets *is* safer and has my preference (and I find it more readable but that's subjective).
Pascal Thivent
@Peter You're right, brackets don't make the code mistake proof, I was generalizing. However, I definitely think that using brackets is safer and I don't see the point of using a weaker solution.
Pascal Thivent
I regard redundant ceremony as less readable and usable with a higher maintenance burden, rendering it as "weaker" in my opinion. Both ways are valid as long as they are intentional, weigh appropriate concerns, and are consistent. Btw, avoid RoR if you love ceremony, as it often goes as far as using convention over more overtly defined relations.
Peter DeWeese
+4  A: 

The simple fact is, adding the brackets will induce fewer mistakes. I think once properly formatted the snippets are equally readable.

Tony Ennis