|
Chris, you can't BS me, come on man. You honestly expect me to buy that not using brackets for a single-line if condition makes code harder to maintain? Seriously? Where's the joke icon?
Jeremy Falcon
|
|
|
|
|
Sure it's easy, until another developer adds a second line and forgets to add brackets.
I've been working in some source code that didn't use brackets for single statements. I introduced a few bugs by not adding them when I had to and I've been wondering more than once if the original developer REALLY meant not to add brackets....
if (condition)
DoThis();
else
DoThat();
DoAnotherThing(); is really weird to look at and at the very least makes you wonder if it was intended...
Especially if DoAnotherThing(); isn't properly in/outdented!
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
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.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: it's still not worth the trade off of having really extra long files / routines
It's really very much worth it. Look at it this way, if (it prevents a subtle bug from going into production (and dependent on your internal processes that chance may be a considerable risk)) { you may have saved that company downtime or wrong data and dependent on the size of that company a whole lot of money! } else { you just scroll a bit extra (it's negligable) and no one gets hurt... }
Jeremy Falcon wrote: so you can give them a hard time.
If the new guy screws up I'm the one responsible and I can get to fix whatever he broke, so that joke's on me 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Not being able to see your code as a whole can also cause much harder to spot subtle bugs as well. Still not worth the trade off.
Besides, you're forgetting this[^].
Jeremy Falcon
|
|
|
|
|
Your automated tests should prevent a subtle bug even making it into the testing environment.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
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??
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
The trap isn't that hard to spot though. Seriously man, we're not talking about something difficult. It's just a peeve. We can debate, but that's all it is. Just a peeve. And my preference is that I'd rather see more of the file, because it's not that hard to spot.
Jeremy Falcon
|
|
|
|
|
I am currently working on a system where most of the software was written in C in the early 1980s. It is formatted so badly that stuff like
if (condition)
DoThis();
else DoThat();
DoAnotherThing();
is not uncommon at all. Add to that, there is no consistent use of tabs vs. spaces, no consistent tab stops, no naming conventions.
Honestly, use the braces or don't, just be consistent, dammit. Proper indentation is far more valuable than brace usage; don't use TAB for indentation, and do stuff the same way, every damn time.
"The only thing a free man can be forced to do is die."
"The right to defend oneself and ones neighbors is the beginning of freedom."
"Freedom? That is a worship word. . ."
-- Cloud William
"It is our worship word, too."
-- James T. Kirk
|
|
|
|
|
it certainly is harder to maintain.
i can't count how many times i've had to fix something in code that only uses brackets when one or more statements are being controlled. so you get stuff like:
for (i=0;i<10;i++)
for (x=0;x<10;x++)
if (xyz) foo()
else for (z=0;z<10;z++)
bazinga();
bar();
and then you have to spend precious brain wattage figuring out that bar(); has nothing to do with any of the rest of it.
this isn't 1967, 3 bytes for a bracket and an CR/NL isn't going to run you out of punch cards. make the code readable!
|
|
|
|
|
Hear hear.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
The rule that I have is that you omit the braces iff the statement is a simple single line. Also, if either branch needs braces then both get them, and loops always have braces.
|
|
|
|
|
but that's the start of the problem!
someday, someone is going to have to come along and add some more logic in that if, and you've just forced them to do the work you should've done the first time!
IMO
|
|
|
|
|
I understand your point of view, but still prefer my way of doing things. What I find more troubling is that after working on a bunch of javascript, I'm starting to prefer the old school C style brace layout.
|
|
|
|
|
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.
|
|
|
|
|
You beat me to it man. If it's hard to read then I use them. For simple things concise wins. +5
Jeremy Falcon
|
|
|
|
|
I have to {
disagree.
}
I prefer the verbosity and clarity that the braces bring to the code.
Jeremy Falcon wrote: Concise wins, unless it's hard to read.
Which is usually what happens. People that use the latter form also tend to be the ones that crush every line together so that you first have to separate to properly understand. Is there a lack of space on your screen?
In any case a method bigger than a screen is just plain fugly. 
|
|
|
|
|
Karel Čapek wrote: I prefer the verbosity and clarity that the braces bring to the code.
You should try VB then.
Jeremy Falcon
|
|
|
|
|
Heathen! Blasphemer! How do you even know that VB uses braces???
|
|
|
|
|
Ha. Well you see... I work for the devil, but it's only because I'm evil.
Jeremy Falcon
|
|
|
|
|
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
|
|
|
|
|
As much as I'm not a fan of that (even in JavaScript), that makes more sense than:
if (expr)
{
doSomethingForOneLine();
}
else
{
doAnotherThingForOneLine();
}You're version is at least concise, and no matter what some may say on CP, concise is important. Less is more. Always will be.
Jeremy Falcon
|
|
|
|
|
I personally prefer this convention:
if ((a cond b) conjunction
(c cond d) conjunction // Additional conditions always on separate line
(e cond f)) { // Always include opening brace
do .... something
} // Always closing brace
Or
} else { // Always closing brace..else..opening brace
do .... something else
} // Always closing brace
The same conventions and principles apply to loops (for, while, etc.) and other conditionals.
I strictly avoid NOT using braces under any circumstances.
I want to be able to see a complete thought, i.e., a block of code, in one intact, obvious section.
These are my thoughts based on years of chasing bugs, modifying other people's code, and having to debug somebody else's problem. Other people are welcome to use their own conventions, but I may not be able to help them efficiently.
Just because I can do something doesn't mean I should do it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
