Hacker News Reader

Comment by strommen | Hacker News Reader

Making braces optional in single-statement if/else/while/for clauses is one of the biggest anti-features in C. It's frustrating that it was ported forward to more modern languages like Java, JavaScript, C#, etc.

I'm glad Python (with semantic whitespace) and Go (with gofmt) solve this problem.

View on HN

> one of the biggest anti-features in C

Please. I'm as big a C apologist as you'll find and even I can think of six or nine thing objectively worse about the language.

This issue is merely a great bike shed because it allows all of us rabble to join in on a discussion about "compiler" technology.

Look: it's a good warning. People should clearly use it. It probably should have been written long ago, and probably would have if our editors hadn't been enforcing this since time immemorial.

And now we've got the warning, we can go back to leaving the braces out more often ;)

Good point, there's plenty of bad stuff about C.

But optional braces are perhaps the most pointless anti-feature in C. The only benefit is a minor (and subjective) improvement in aesthetics.

Your point being that... aesthetics in a technology (a "programming language") whose whole existence derives from making computer programs easier to write, read and reason about is... unimportant?

There's probably a word that the parent was looking for; it wasn't quite aesthetics, at least as you've defined it.

Sometimes you can write code that looks "prettier", at the expensive of the ability to read and reason about it. Optional braces are frequently used for this effect. Yes, optional braces allow you to fit more code on the screen with less noise—and therefore could be thought to enhance some kind of readability. But at the same time, they require you to think harder about the grouping of the code around them. Unless you've got a reformatting linter, you could have code like this:

    if(foo)
      bar; baz;
    quux;

and optional braces require an extra subroutine to be constantly running in your head, looking for those mis-arranged `baz`es that will get executed anyway. That cognitive load detracts from your ability to read and reason about the code.

(What'd be really interesting, in my opinion, would be to make C's braceless blocks, and only braceless blocks, have semantic-whitespace. Then the above would be able to be easily reasoned through: `baz` is part of the conditional, because it's on the same line. But this breaks a lot of rather old and inflexible assumptions about how C is parsed, that macro-writers et al depend on.)

  >I'm glad Python (with semantic whitespace)... solve this problem.

Python solved it....then added the problem of making things you can't even see semantically significant. If you write Python, it's helpful to have an editor that makes the difference between tabs and spaces visible....

Since Python 3 the interpreter will halt when detecting mixed whitespace, forcing the programmer to deal with it.

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

This is only a problem in Python 2.

> it's helpful to have an editor that makes the difference between tabs and spaces visible....

I do this for any and every language. Mixing tabs and spaces always sucks.

I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language.

In the sense that a programming language is not only made to be parsed by a computer, but also read back by a human.

Yes, and that the nuances of how things are formatted are really not that important, but rather having a standard which provides a consistent reading experience is the important aspect.

I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.

And in the case of go that standard is language wide, not just project, team, or company wide.

Except the go standard is awful, so a language-wide formatting requirement with bad defaults makes the language basically unusable (since programs are made to be read, not run).

I think that's one of the best contributions golang has made to the programming world. The idea that the language itself should be easy and unambiguous for the compiler and the human to parse. And that a single formatting standard makes life easier for everyone.

If we ever move beyond using text files for storing code, we could eliminate formatting differences entirely... but efforts in that direction have run into many issues in the past.

> I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language.

gofmt is still optional. Python significant white spaces are not.

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

> I thought that the go compiler would throw an error of your code is not in the format produced by gofmt.

This is not the case.

Nope. The gofmt-contract is a purely social one. But it's one held by nearly the entire go community which probably gave you that impression for good reason.

Wow, true. The first thing that I read was how to set up emacs to run gofmt every time you save a src file. After that, I never questioned it.

Actually for C there has always been GNU indent, which serves a similar function as gofmt.

Rust does something similar. It doesn't allow for brace-less clauses and it also bitches and moans at you about 'miss-using' camelCase, snake_case, etc. Which is great because it means that by default all project will follow a similar mark-up.

We also have 'rustfmt' in development, which goes even further than the built-in lints.

Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site:

  if (ptr) call_oldschool_thingy(ptr);

I'm not sure that expanding your statement to multiple lines is any less "useful". I suppose in certain cases it can make code much more verbose, as one line effectively becomes 3-4, which can make it harder to navigate.

Fairly often there's a whole sequence of this type of calls. For example cleanup of multiple objects:

  if (image) foo_release(image);
  if (label) foo_release(label);
  if (data) foo_buffer_destroy(data);
  if (window) foo_window_destroy(window);

It's easier to see that all objects are being cleaned up when each occupies just one line, as that typically matches the look of the initialization:

  window = foo_window_create();
  data = foo_buffer_create(1, 2, 3);
  label = foo_label_create(window);
  image = foo_image_create(window);

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those.

The second example is missing error checking. So the real code isn't that nice.

My point is that C shouldn't look like Python. Small amount of functionality should be written unambiguously and take a lot of space if necessary. Because of the nature of C, it needs a lot boilerplate, and will take a lot of screen space anyway, but that is not a problem, as we are not coding on paper.

How would you use the ternary operator there? Like this?

    image ? foo_release(image) : 0;

Yes. And cast that 0 to (void), so the compiler won't complain over an unused expression.

Any C programmer will recognize what (void)0 means, do nothing.

Sure, but I find it strange to use the ternary operator and discarding the value. It's not wrong, but I think most C programmers prefer a simple if statement.

I was giving an replacement for the if statement presented above, where both expressions are on the same line.

I'm closing in on year 25 of programming in c, and I still refuse to use the ternary operator.

It would be really nice if instead of downvoting, someone could provide a counterargument, or comment on parts the disagree.

I downvoted it to indicate that I don't agree with your preference. I rarely downvote for disagreement, but this was a case where I thought it worthwhile to offer the feedback that others strongly do not share your view. My equally strongly felt subjective personal belief is that single line if statements without braces are fine, but that once a second line is required braces should be mandatory.

I find the single line "if" statement without braces to be clearer and simpler than ternary with a (void) expression, and don't think the downsides are significant. It breaks if you were to add another statement after the semicolon on the same line, but I think that should almost always be avoided anyway.

I do find it interesting that others prefer two-line without braces over the single line approach. I find this one to be more dangerous than the single line. Possibly because with line-oriented debuggers it can be hard to set the right breakpoint?

It's quite possible that others are downvoting because they think you are trolling, and that no one would actually believe the ternary operator to be clearer. I wondered also about your defense of Allman braces, which I didn't downvote because I think it's a good example of how different the others's views can be on what seems obvious. While I think (some of) your views are in the (very small) minority, please keep posting them!

Braces don't prevent you from using single-line if:

  if (ptr) { call_oldschool_thingy(ptr); }

many people use specific styles for where to place { and } (e.g in a line by itself) so this might look 'ugly'

Nothing prevents them from not using single-line ifs.

Meshes perfectly fine with one true brace style

Was just discussing this at work. A good compromise would be to allow statements outside of of block-parens only when they are on the same line as the control statement.

IMHO there should be a -W to enforce this so those of us with -Werror on can catch it and burn it with fire.

Here at Google the style guide requires block-parens always.

In the project I work on our style also requires block-parens. Sometimes it feels unnecessary, but it does make up in terms of consistency: it's easy to glance through the code and inspect the conditions only.

I got used to this quite a bit and these days if I write code outside the project I work on, I d sometimes omit the block-parens, but I always add extra indentation to ensure the condition is visually well-separated, e.g.:

  if (condition1 || condition2)    execute_foo1(with_bar);
  if (condition3)                  exectute_foo2();

Both Rust and Golang have optional parens and mandatory braces, so for the same number of keystrokes one would have something more like:

    if ptr { call_oldschool_thingy(ptr) }

(Keystroke count isn't an important metric for me, but apparently very important to some people.)

I love this style. Braceless style always breaks when refactoring or adding/removing debug logging – so it makes sense to make the braces mandatory. And then, because you have a delimiting if and the starting brace, you don't need to have the parenthesis. Great!

Now if only Rust supported the elision of ; ... (Yeah, I know that they have a reason to not do that, but I don't buy it.)

Does this outweigh the disadvantages? I don't think so.

I've never met a C or C++ debugger that handled this case nicely, unfortunately. Totally ridiculous, of course, because they could! They just never seem to.

Meeting snippets of code like that when debugging is a constant source of frustration for me, because I have to stop what I was doing, edit the code, rebuild, then get back to where I was. Particularly galling when the code in question is in a commonly-included header, and the subsequent build takes several minutes, and I was on a particularly productive-looking trail.

(The last project I worked on solved (?) this problem by performing so shamefully poorly in an unoptimised build that it effectively didn't work. So you had to debug the optimised build. And so single-stepping at the source level just didn't work properly anyway.)

  >I've never met a C or C++ debugger that handled this case nicely, unfortunately.

Apparently you never use Visual Studio. It can highlight a portion of the statement on each step (at least it used to)

Last I looked, this only worked for C# (possibly all CLR-based languages...) - but native C/C++ breakpoints were addressed by file and line only.

That's likely because with C#, the debugger can use deoptimization and on-stack replacement to get expressions evaluated in the order they happen in the code, as long as the instruction re-ordering happens only in the bytecode to native code compilation. Even though the debugging symbols just have line numbers, the debugger could potentially regenerate they bytecode to figure out which operations correspond to which expressions.

In C++ optimized builds, you might be jumping back and forth between lines due to the compiler re-ordering instructions, and there isn't an easy way to get back code that's in-order.

Haskell's solution to this problem is also excellent and needs to be better known and copied into newer languages. The language has curly braces around the bodies of 'let', 'case', 'where', and 'do' constructs, and also the bodies of modules, and semicolons between the constituents of those constructs -- but when the compiler demands a '{' and doesn't see one, it uses indentation to insert them in the obvious places. If your indentation is incorrect, you're likely to get an implicit ';' or '}' put in the wrong place, and you go fix it.

The scheme works so well that people will often go months into their Haskell education before they encounter code with explicit braces and semicolons.

I've actually never seen production code with braces or semicolons. The only place it's semi-common is when people write complicated expressions and need to put them on one line for the REPL (GHCi).

I think another use-case for non-layout version is generated code. If you happen to generate Haskell code, it's easier to keep the syntax correct with the explicit notation rather than the implicit whitespace version.

I don't like Python forcing you to use a particular identation. And in my opinion optional braces are not an anti-feature, "with great powers come great responsibilities": like any other tool it's up to who is using it to use it in the right way.

I would disagree that optional braces are a "great power." I feel like it's a really nothing feature.

> like any other tool it's up to who is using it to use it in the right way.

And mandatory seat belt use is foolish, bike helmets are for wimps, and blade guards on saws are a waste of space and money.

Just use those tools responsibly :P

I don't find something like the below frustrating really

if (a)

...

else

...

But for some reason I find the below _very_ frustrating. It feels misleading and I find it to be very, very ugly.

if (a)

...

else {

    /* Multi line block */

}

I've actually never seen anyone do either of those.

I've seen

if (a) thing;

but never with an else, and certainly never with an else that has a multi-line block. That's definitely somethign I'd call out in a CR.

I call it out in CRs when I see it and I've been fixing any of these I come across in code at work.

I'd rather a compiler forces me to put braces around everything than let people have the opportunity to do something like the latter from my original comment.

Why is that an issue? You would use something like that extensively in Go or JS for example, where you need to perform a check on the returned (Go) or passed (JS callback) error value.

The else is executed if there is no error, in my style at least, so naturally it will contain more logic.

I just have a problem with the mixing of braces on an if/else chain I guess. I don't know how to explain it clearly, it just rubs me the wrong way?

In Rust, code like this simply won't compile http://is.gd/e6mBlG

Well, yeah, but that's not a huge advantage of Rust. In any language where that's not an allowed construct (and there's quite a few), it won't compile. It won't compile in Perl either (It fails at the compilation stage, not at runtime).

I agree. I've trained myself to religiously apply curly braces to all blocks, but it'd be more reassuring to know there was a compiler check for it. I do have linters set up to check for it, but I just wish it were default.

This is also one of the reasons I like Racket: there's no such thing as ambiguous block delimitation. Also, everything-is-an-expression is very useful.

> Making braces optional in single-statement if/else/while/for clauses is one of the biggest anti-features in C.

What's frustrating is that K&R still has a lot of example code like that as well. It would be wonderful to see a 3rd edition even if it do nothing but change its code to use braces.

Reply on news.ycombinator.com