Hacker News Reader

Comment by AdmiralAsshat | Hacker News Reader

I'm in favor of braces around everything, but to be honest even I will occasionally use the indent if I only expect one action. e.g.

  if (true)
    foo();
  else
    bar();

This looks prettier to my eyes than

  if(true){
    foo();
  } else {
    bar();
  }

However, I might not be the last person to touch the code. My coworker might come later and add:

  if (true)
    foo();   
  else
    bar();
    baz();

And hence the indent problem.

View on HN

Even if you ignore safety, braces are still better because if need to edit the code later, you won't need to change as many lines, so the source control history will be cleaner. (Similar to adding a trailing "," to lists that don't strictly need it.)

I always opt out of the "no braces needed thing," it is my feeling that you should stick to the more "all around" method of writing something so you never need to switch back and forth..

Prettier but potentially dangerous? That's the core of the problem, I believe.

I agree. I don't care much about if something looks good, but rather if it works well.

Everything is potentially dangerous. I mean, pointers, anyone? So many things that can go wrong with those.

And besides, code is for humans to read and only incidentally for computers to execute. Might as well optimize for prettiness.

This is the poster case for "code is for humans to read, so it shouldn't be easy to mis-read." Braceless misindented ifs are everything except easy to read.

Btw, I suppose you wanted to add baz() after bar(). Adding it after foo(), as you did, will not compile.

Thanks, I fixed it.

Why should the inability to write basic C preclude me from being allowed to pontificate about brace style like the greats?

How about this one

(true) ? foo() : bar();

They will send the Inquisition after you for that one! :)

Well I'm Spanish after all ;)

In cases where I have only one statement I often drop the braces, but I also drop the newline.

  if (true) foo();
  else bar();

Not much room for a confused baz() here, or so I hope.

This is actually a worse solution. When speed reading code having control statements on their own lines is far more beneficial as you can at a glance, using the indentation, easily see what the flow of execution is.

You might find it worse, I don't. You might not be able to parse this quickly, I am.

No holy wars about style please! I was just offering an alternative that works well for me.

I agree. But your last example won't compile anyway. Though this would:

  if (true)
    foo();
  else
    bar();
    baz();

But I have to admit if you ever actually do that, you have failed to fundamentally understand how your code is executed. No braces means one statement. Period.

In these cases languages which are auto formatted (C#, go-fmt, etc) likely have an advantage where these problems stick out more obviously.

But I have to admit if you ever actually do that, you have failed to fundamentally understand how your code is executed

I would say I have a pretty good understanding of how C & my code in general works, I'm currently trying to create a threadpool with support for co-routines/yielding to other threads in userspace. Nothing super fancy, but not something you can do without understanding how code is actually executed ;)

But I still lost an hours work last week because I hadn't put a brace after an if statement and when I came back to it, I didn't notice the lack of braces and put an extra statement behind it. This is why I usually stick to putting braces around everything.

Personally I'm a fan of braces everywhere (though I prefer Allman style), but the one area where I've given up is precondition checks at the start of a function.

Any style with braces looks like a cluttered mess compared to

    if (foo)
      throw ...
    if (bar)
      throw ...
    if (baz)
      throw ...

But I strictly limit that to the beginning of a function, and only `if (x) [throw|return] y;`

> Personally I'm a fan of braces everywhere (though I prefer Allman style)

you monster.

So much wasted vertical space. We use that at work and I am not at all a fan.

That's why smart programmers use 2x monitors in portrait mode.

Try it once. You'll never go back.

I think I don't really have that bar() baz() problem because I use blank lines to separate blocks of code from each other. And also because as a heathen I use Allman style not K&R.

Reply on news.ycombinator.com