Hacker News Reader

Comment by benihana | Hacker News Reader

Is there a reason there aren't any braces around single-line if statements? Is that a C thing? It seems kind of inviting to bugs to me.

View on HN

It's pointless to argue over these kind of things. Every major project/company has their own codified code style guide, and if you want to contribute/earn your salary then you must follow that style guide to the T. Here's the relevant quote from the Linux kernel coding style[0]:

    Do not unnecessarily use braces where a single statement will do.

    if (condition)
	    action();

[0] https://www.kernel.org/doc/Documentation/CodingStyle

I consider that a bug in their style spec. Single line if statements are known to cause bugs.

That's what I'd thought for may be over a decade. About ~3 years ago I revamped my personal coding style to eliminate as unnecessary baggage as possible. As part of that I stopped using braces for single line if and I'd yet to bump in a bug because of that. Overall I find code looks more compact and cleaner, may be even less friction to read. Nowadays when I see a braces around single line if I get that "oh that's clunky code" feeling in my stomach. Things are worse with C# and lot of Java code where people insist not only having braces around single line if but also have { on its own separate lines.

I think a good language shouldn't have braces to mark blocks in first place. Given indentation,they are redundant most of the times and they just contribute in clunk. This is exactly the case with Python and hence this is essentially a default style and people hadn't be complaining about it's causing bugs.

There's an enormous difference with Python, because the indentation is syntax. These two code snippets, one in Python, the other in C, do not mean the same thing:

  if (condition)
    statement_1();
    statement_2();

Python:

  if condition:
    statement_1()
    statement_2()

Personally, I always use braces in C and C++, even though it is more clunky. I want the assurance. I also frequently have to make changes to code that does not use braces, and then I have to add the braces in because I am adding statements to a conditional. To me, that is more clunky.

I nowadays resist the urge to make syntactically beautiful code if that means that it is a little bit brittle or vulnerable to mistakes.

Wrt. using { }, I omit them if I put the block to be executed on the same line, and usually I do that only with special cases, e.g.

  if(expr1) continue;

  if(expr2) throw new RuntimeException();

I see merit in both sides of the debate. As long as the style is consistent, it should be legible. It is an argument similar to vi versus Emacs -- both can be right. It is more important to be consistent through a project. Adopt one style.

From this day forward, let us proclaim to always use brackets; so that intent is more obvious to the reader.

You can sidestep the braces debate by using a lisp.

To introduce Lisp you need to fight the parens debate instead ...

or you could just use Python

... if you want to get in to the whitespace debate instead

Easily solved by pretending the parens are whitespace. :-D

The answer to the whitespace debate: http://en.wikipedia.org/wiki/Whitespace_(programming_languag...

In the C grammar, braces denote compound statements. Control flow statements can take any type of statement as their body rather than just the compound variety.

It confuses me that it doesn't work for functions. like

    int main() return 0;

In K&R C, the function braces serve to separate parameter declarations and local variables:

    int main(argc, argv)
      int argc;
      char **argv;
    {
      int local;
    }

Thanks, I haven't seen that syntax before.

So as to have more code on the page. It's official style of the Linux kernel [1].

[1]: https://www.kernel.org/doc/Documentation/CodingStyle

Most C-inspired languages (most popular programming languages) allow this. The only ones I've used that don't are Go and Swift. And I find it a little annoying.

If you're worried about bugs, there are other things in C/C++ to criticize first ;)

It's true for Rust as well. What these three languages have in common is that they don't require parentheses around the switching boolean expression, and when you have things like:

    if expression1 expression2

it can be fiendishly hard to determine the boundary between expression1 and expression2.

It's a C-style language syntax option. If it's only a single line in after the if, the braces are optional. I've also seen it in C++ and PHP.

Whether or not it's sloppy is up for debate and just a matter of personal preference.

C# also has it, and i've heard Java has got it as well, but I've never tested it in the latter.

I personally like being able to do it since it allows me to do away with the 2 extra lines auto indent puts in if i add brackets. That's a 50% reduction for a 4 line if. Maybe I should just buy a bigger monitor.

The lead programmer at my last job encouraged us to use it as a way to make sure our conditionals & foreach loops (PHP programmer) weren't doing too much. If we had to use braces, it was a sign to check it out and see if it could stand some refactoring.

I use a plugin called littlebrace for visual studio, which reduces brace lines to like 3 pt font. My C# code has started looking like Python :)

This sounds really neat. Can you drop a link? I browsed around but couldn't find anything.

https://github.com/lukesdm/little-braces looks like the one.

Also see this fork/port to VS2013:

https://github.com/owen2/little-braces

Also, it is available from the online add-in manager if you search for "little braces." The VS2013 community edition is just in time :)

I couple it with the indent guideline plugin for best effect (braces are super small, light lines to track indent level, 2 space indent...).

Or use a better bracing style. Or move to significant whitespace.

"If it's only a single line in after the if, the braces are optional."

Not _line_, _statement_. Consider

  if(flag)
    foo(); bar();

and

  if(flag)
    foo =
      bar +
      baz;

That first example always calls bar().

Warning: I haven't tested this, and am beginning to doubt a bit. It must be correct, but why, then, don't I remember seeing this in underhanded C contests? Combining that with macros allows you to hide the semicolon.

C has potentially ambiguous association on nested "else"s. The habit of too many braces is a safety.

Its common in Java too...

Reply on news.ycombinator.com