Pet Peeve
-
I don't do if() and the code in the same line. It is more a debug stuff. If I want to debug the if itself I put the breakpoint in that line. If I only want to debug the method call, after the if succeeded, I put the breakpoint in the call line.
Here's a Visual Studio trick: To debug the if, make sure the text cursor is somewhere in the if condition and press F9. To debug the method call after the if succeeded, make sure the text cursor is somewhere in the method call and press F9. Happy Debugging :)
-
That works fine until you get this in the code after all :)
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail;When I first saw that bug I got even more convinced see that my approach to braces everywhere as a must works better in the end.
Banking establishments are more dangerous than standing armies. T.Jefferson
I, for example, would never write the code like that. I can write an if without the {}, but I always put an extra line break after the call. And seeing two lines after the if simply looks wrong.
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail; // why the hell there's a line of code here? It is not important what it does, it looks wrong.if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;So, this kind of error is as ugly to me as this (in fact, even uglier as the excessive {} somewhat hide the problem):
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
goto fail; // Doesn't this look wrong?if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}But developers can also commit these errors (and by simply taking a looks without reading the code, I don't spot anything wrong):
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
} // Oh, it looks like an else is missing...
{
goto fail;
}if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}// So the code gets corrected to...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
else
{
goto fail;
}if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
} -
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
I personally prefer the former of the two, for readability. I tend to "speed read" classes and utilize the curly brackets as logical breaks in the code. Basically, for me, it differentiates between code indentations and logic (if, foreach, for, etc.)
ICP-Fan (The Keyboard Wielding Maniac)
-
Here's a Visual Studio trick: To debug the if, make sure the text cursor is somewhere in the if condition and press F9. To debug the method call after the if succeeded, make sure the text cursor is somewhere in the method call and press F9. Happy Debugging :)
Imagine the if and the call are in the same line. Yet, the condition is false 99% of the time. Also, the method being called is called from many other places. If things are in two lines, simply put the breakpoint inside the if, not on the if line. If it is in the same line, you can't do that. Putting the breakpoint inside the method call will not help either, as it is called from many other places, so the best you can do is to create a conditional breakpoint. I prefer to have things in two lines and put the breakpoint exactly where it is needed.
-
I prefer
if (something) DoAB();
for the latter. I never use it, but have recently come across it. It seems more readable to me.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
Brady Kelly wrote:
I prefer
if (something) DoAB();
for the latter. I never use it, but have recently come across it. It seems more readable to me.
Me too, if you must omit the braces then it's best to put it on one line. That way you don't have to worry about someone coming along later, not paying attention, and doing this:
if (something)
DoA();
DoB(); -
I agree with you. And I am actually the kind of person that when has to modify something like:
if (something)
{
DoA();
DoB();
}To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency. So, it becomes:
if (something)
DoAB();Paulo Zemek wrote:
I agree with you. And I am actually the kind of person that when has to modify something like:
if (something)
{
DoA();
DoB();
}To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency.
So, it becomes:if (something)
DoAB();Are you serious? You re-factor and combine methods just so you can avoid braces and use a dangerous bad practice?
-
Paulo Zemek wrote:
I agree with you. And I am actually the kind of person that when has to modify something like:
if (something)
{
DoA();
DoB();
}To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency.
So, it becomes:if (something)
DoAB();Are you serious? You re-factor and combine methods just so you can avoid braces and use a dangerous bad practice?
No, I don't refactor and combine methods... I was only giving an example. What's more probably is that I extract an entire block (with many calls) into a single method. But for the example I used two calls.
-
:thumbsup: Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.
PIEBALDconsult wrote:
Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.
Just for making that statement, you should be forced to a maintain decade-old Perl CGI system.
-
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:
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.
-
I'm not lazy, but I'll still use the latter. There's no point in always having to use a bracket so I don't, unless it makes things easier to read. Which in your example it doesn't. Wasting space just makes a source code file longer anyway and harder to navigate. Concise wins, unless it's hard to read.
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
-
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 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
-
PIEBALDconsult wrote:
Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.
Just for making that statement, you should be forced to a maintain decade-old Perl CGI system.
Perl is a scripting language; not a programming language.
-
I, for example, would never write the code like that. I can write an if without the {}, but I always put an extra line break after the call. And seeing two lines after the if simply looks wrong.
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail; // why the hell there's a line of code here? It is not important what it does, it looks wrong.if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;So, this kind of error is as ugly to me as this (in fact, even uglier as the excessive {} somewhat hide the problem):
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
goto fail; // Doesn't this look wrong?if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}But developers can also commit these errors (and by simply taking a looks without reading the code, I don't spot anything wrong):
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
} // Oh, it looks like an else is missing...
{
goto fail;
}if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}// So the code gets corrected to...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
goto fail;
}if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
else
{
goto fail;
}if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}Well, I won't write anything such as that either. But since this a real world example of infamous 'goto fail' bug obviously other people do. In general I'd say that none of your samples with braces would've passed my code review, but I admit your first sample should attract review attention as well, it'll probably will attract enough attention from any reviewer. Still I'd say that with braces style the code like that most probably would not leave the developer and will be fixed before review
Banking establishments are more dangerous than standing armies. T.Jefferson
-
Perl is a scripting language; not a programming language.
Yeah true, you really need to be pedantic about a joke?
-
LOL, that looks exactly like T-SQL :)
-
Yeah true, you really need to be pedantic about a joke?
No, but I really need to be demeaning of Perl. X|
-
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
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.
-
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
Karel Čapek wrote:
For example, how hard is it to
Both are probably less hard than complaining about it. But other than that since it is legitimate syntax then it is legitimate syntax and nothing but a preference after that. Naturally if that is the most important problem facing you day to day or even one that even rises above the noise level in terms of problems you must work at an exceeding stellar place. I once worked a a place where the VP (most senior person in the entire site) would regularly take down the database through incorrect usage which would shut down the call center (several hundred employees) completely. Now that is a problem.
-
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.
It's interesting that the older the programmer the more concision becomes important. :)
Ron Christie