5 ms·
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(); e
by AdmiralAsshat 11y ago
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.
- asendra 11y agoHow about this one (true) ? foo() : bar();
- gravypod 11y agoI 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..
- iainmerrick 11y agoEven 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.)
- pif 11y agoBtw, I suppose you wanted to add baz() after bar(). Adding it after foo(), as you did, will not compile.
- AdmiralAsshat 11y agoThanks, I fixed it. Why should the inability to write basic C preclude me from being allowed to pontificate about brace style like the greats?
- Piskvorrr 11y agoPrettier but potentially dangerous? That's the core of the problem, I believe.
- gravypod 11y agoI agree. I don't care much about if something looks good, but rather if it works well.
- Grue3 11y agoEverything 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.
- Piskvorrr 11y agoThis 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.
- hacker_9 11y agoI 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.
- Coding_Cat 11y agoBut 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.
- _0ffh 11y agoIn 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.
- hacker_9 11y agoThis 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.
- _0ffh 11y agoYou 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.
- Merad 11y agoPersonally 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;`
- Gibbon1 11y agoI 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.