Pet Peeve

[Vark111]

I only remove braces on single-line method preconditions at the beginning of a method:

if (arg==null) throw new ArgumentNullException("arg", arg);

Everywhere else I put braces.

[Jim from Indy]

You guys need to investigate APL, a language described by one of my fellow students as "the ultimate in elegance"

Jim

[Johnny J]

Vark111 wrote:

if (arg==null) throw new ArgumentNullException("arg", arg);

Let me guess - You're used to dealing with Pirated software??? ;)

Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time

[rjmoses]

Too much whitespace/not enough whitespace. The "Great Debate" goes on. Some programmers get paid by LOC, so they're induced to spread things out. Some programmers like to show how smart they are, so they try to condense everything to one line of cryptic functions. Other programmers heard "this" is the right way to do it. For me, the key is "consistency". I want my code and all my programmers' code to look identical. It should be totally transparent who wrote the code. And the code needs to be clear, quickly comprehensible and understandable, yet concise. I don't want to spend my time figuring out what John Doe was doing and maybe miss some key element when I'm under pressure to fix a problem or develop a new capability. I tell my programmers that "I was around long before you came and I will be around long after you leave. Do it my way because I will have to maintain it later." I just had to work on a one-liner script from another company that incorporated at least 12 function calls. Took me the better part of a week to figure out where the bug was. Yes it looked slick, but a week wasted is two weeks lost. That's my thoughts--clear, comprehensible, concise.

[tom1443]

I don't care what way you do it as long as it is not: if (something) { DoA() } Yuck! But seriously - if the biggest problem your project has is where people put or don't put the braces you are doing pretty good.

[agolddog]

Correct. If you have a 'rule' which says, "(don't) use braces, except in these special cases", then you have to remember the special cases. I'm in the braces-good camp for the reasons Chris supplied above. Missing them doesn't make your code noticeably more concise, and does make your code (and, more importantly, your intentions, when you've run away from this project and I'm trying to figure it out [or vice-versa]) noticeably more readable.

[Jeremy Falcon]

You beat me to it man. If it's hard to read then I use them. For simple things concise wins. +5

Jeremy Falcon

[DenverEd]

It's 2014, who cares how long the code file is. It's easier to read with the extra {}, it's easier to maintain with the extra {}. The only downside is typing extra {}. Don't you get paid per line anyway??

[Jeremy Falcon]

I care. Being able to see more at a glance is nice. It's also less convoluted when it's a simple statement. And I don't get paid per line, nobody does. I get paid to deliver a product that's useful. Nobody cares about line count except other nerds / devs.

Jeremy Falcon

[R Giskard Reventlov]

Fabio Franco wrote:

Did it occur to you that it may be about style and not laziness?

No: people who do this tend to shortcut other things (sweeping generalization and/or observation over many years of being a coder) or crush the code into as small a space as possible making it hard to read. The point is really to have consistency of style and format in the code: braces make it easier to read. Consider this:

int a = 0;
string bean = "green";
float golden= 1.618;
if (condition)
{
x = 42;
bean = "eatme";
golden = a * pi;
}
else
a = 1;
bean = 'foo';
golden = a - x;

I find that style difficult to read and adding the braces would make it much easier to see the flow. Oh, and then there are tabs v spaces... :-)

[RJ Hatch]

Here's a Visual Studio trick: To debug the if, make sure the text cursor is somewhere in the if condition and press F9. To debug the method call after the if succeeded, make sure the text cursor is somewhere in the method call and press F9. Happy Debugging :)

[Paulo Zemek]

I, for example, would never write the code like that. I can write an if without the {}, but I always put an extra line break after the call. And seeing two lines after the if simply looks wrong.

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail; // why the hell there's a line of code here? It is not important what it does, it looks wrong.

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

So, this kind of error is as ugly to me as this (in fact, even uglier as the excessive {} somewhat hide the problem):

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
goto fail; // Doesn't this look wrong?

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}

But developers can also commit these errors (and by simply taking a looks without reading the code, I don't spot anything wrong):

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
} // Oh, it looks like an else is missing...
{
goto fail;
}

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}

// So the code gets corrected to...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
else
{
goto fail;
}

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}

[robertschoenstein]

I personally prefer the former of the two, for readability. I tend to "speed read" classes and utilize the curly brackets as logical breaks in the code. Basically, for me, it differentiates between code indentations and logic (if, foreach, for, etc.)

ICP-Fan (The Keyboard Wielding Maniac)

[Paulo Zemek]

Imagine the if and the call are in the same line. Yet, the condition is false 99% of the time. Also, the method being called is called from many other places. If things are in two lines, simply put the breakpoint inside the if, not on the if line. If it is in the same line, you can't do that. Putting the breakpoint inside the method call will not help either, as it is called from many other places, so the best you can do is to create a conditional breakpoint. I prefer to have things in two lines and put the breakpoint exactly where it is needed.

[StatementTerminator]

Brady Kelly wrote:

I prefer

if (something) DoAB();

for the latter. I never use it, but have recently come across it. It seems more readable to me.

Me too, if you must omit the braces then it's best to put it on one line. That way you don't have to worry about someone coming along later, not paying attention, and doing this:

if (something)
DoA();
DoB();

[StatementTerminator]

Paulo Zemek wrote:

I agree with you. And I am actually the kind of person that when has to modify something like:

if (something)
{
DoA();
DoB();
}

To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency.
 
So, it becomes:

if (something)
DoAB();

Are you serious? You re-factor and combine methods just so you can avoid braces and use a dangerous bad practice?

[Paulo Zemek]

No, I don't refactor and combine methods... I was only giving an example. What's more probably is that I extract an entire block (with many calls) into a single method. But for the example I used two calls.

[StatementTerminator]

PIEBALDconsult wrote:

Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.

Just for making that statement, you should be forced to a maintain decade-old Perl CGI system.

[StatementTerminator]

Jeremy Falcon wrote:

Ok, you have a good point with that, but it's still not worth the trade off of having really extra long files / routines. Besides, it gives you something to spot the new guys with so you can give them a hard time.

Who cares how long the files are? They aren't being printed on paper (hopefully), and scrolling is not so hard. Setting a trap for junior programmers that introduces a bug is not responsible programming. If you do that, you are responsible for the bug, not the newbie, and you should be "given a hard time" for compromising the code base just to be a jerk.

[ronchristie]

I both agree and disagree. My personal coding style is:

if (expr) {
doSomething();
}
else {
doAnotherThing();
}

I like using the braces so that adding an extra bit of logic to the execution block won't inadvertently change the program flow, and at the same time placing the opening brace on the same line as the if... and the else statements compacts the code a bit. To me the advantage with compact code is that you can see more of the program logic in a single screen which means less time scrolling up and down trying to follow the program logic. For that reason, I'm ruthless in eliminating blank line whitespace except to visually offset functions or methods.

Ron Christie