Books tend to use the first style because it saves a line, which is something worth considering when you have limited space on your page
Personally, though, I prefer the second style, and it's also the one most prominently used in Ogre.
I always use the second style as it make code more readable.
Also blind people find it easier with there reader software. I worked with one for 3 weeks on a POC and someone kept putting it the end and he asked for us not to as it slowed him down alot.
The reason I belive was the line reader software follows the cursor but skips white space. so placing it at the end they have to listen to the full if statement to know the next line is inside the if statement but placing it on the next line the can jump past knowing they are in the if statement code.
Simple thing but makes a huge difference
There are 10 types of people in the world: Those who understand binary, and those who don't...
The if(condition){ style tends to be used more in scripting I find, lots of web based code will use this. As it's my primary development environment now days I tend to carry it over into my c/c++ code. The second style does make matching your opening and closing braces easier without using any ide features.
Kojack wrote:I like the visual symmetry of matching indented braces.
I vastly prefer this as well. I help maintain a lot of php, C, and some C++ code, some of it a decade old. The second style makes quickly getting to grips with code you haven't seen before much easier. That and consistent indenting. I don't care if you use tabs or spaces, 4 or 2, or whatever as long as it's all the same!
<slightlyofftopic>
Interestingly I can often guess the author of some code in our system code base by the style, and techniques used, variable names etc.
</slightyofftopic>
"He'd never realized that, deep down inside, what he really wanted to do was make things go splat." Terry Pratchett, Reaper Man
<slightlyofftopic>
Interestingly I can often guess the author of some code in our system code base by the style, and techniques used, variable names etc.
</slightyofftopic>
Same and that means I have to go tell them off because they have breached coding standards
There are 10 types of people in the world: Those who understand binary, and those who don't...
I'm like all the others, for the same reasons, in particular symetry that in C++ is kind of totally adequate because of the symetry of constructor/destructors that you need to keep in mind to use RAII correctly.
Zonder wrote:Same and that means I have to go tell them off because they have breached coding standards
Unfortunately I can't do the same - often those particular coders have moved on a long time ago. The joys of code maintenance!
What does every one think of 'Yoda expressions' where you put a constant on the left side of a equality test.... I've started using them again for php code, as I've had a couple of bad bugs caused by a single character typo! (C, and C++ compilers usually warn you of these)
"He'd never realized that, deep down inside, what he really wanted to do was make things go splat." Terry Pratchett, Reaper Man
I make sure my code don't have such un-english-language-like trick.
Even compilers does points you when you try to do assignation in a test, so I don't see the point.
I guess they feel smart using that trick but I prefer to be trainned to write the correct operators instead of being trained to not have to be trained to write the correct operator...
Never heard them called 'Yoda Expressions' before, but it's simply good practice, when doing an if statement, to have the lhs be const. It helps to reduce bugs.
If something helps to reduce bugs, and it's free, you do it.
zootlewurdle wrote:Never heard them called 'Yoda Expressions' before, but it's simply good practice, when doing an if statement, to have the lhs be const. It helps to reduce bugs.
But it then doesn't read correctly. If true equals variable makes far less sense than if variable equals true. Plus, any decent compiler will warn you if you use assignment in a condition.
Yacoby wrote: Plus, any decent compiler will warn you if you use assignment in a condition.
And that is exactly the kind of assumption that leads to bugs.
Makes no difference to me, it's the coding standard where I currently work and my previous employer. I also don't see it as back-to-front. It's if thing expression thing. I'm not quite sure why if( 0 == pointer ) is harder to understand than if( pointer == 0 ).
It's a matter of preference, I suppose. I, too, prefer pointer == 0 over the other way around, it just feels more natural for me. Doesn't mean I couldn't understand the alternative, of course.
Some languages don't even allow assignment in if clauses (or similar constructs), which I find a sensible choice.
The use of Yoda expressions are often found in Java code primarily because it eliminates the need for the developer to check for specific conditions and is by far the cleanest way to write the code.
String myVariable = null;
// Will not through NullPointerException
if(AppConstants.SOME_CONSTANT.equals(myVariable)) {
}
// Throws exception since myVariable is null
if(myVariable.equals(AppConstants.SOME_CONSTANT)) {
}
// Doesn't throw exception but is not as clean to read
if(myVariable != null && myVariable.equals(AppConstants.SOME_CONSTANT)) {
}
But when it comes to C/C++, I prefer the standard notation of (pointer == 0) as it just seems clearer of the statements intent.
There should never be assignments in an if clause, in my opinion that's bad practice.
But what's better though. Compilation failing because the programmer accidentally used one '=' when two were intended, or to have the compiler blurt out a warning which could easily be missed when you're compiling a ton of code on a very large project? Especially when you're working on a large multideveloper project which is silently compiled overnight which spits out an executable for QA to test the following morning?
The former cannot ever be missed, the latter can be easily missed and can be hard to track down. Been there, done that XD.
I've never understood the readability argument. I had that with one of my colleagues where I work. Whenever that point comes up I'd basically need to agree to disagree. The above point still stands though.
I've always put the bracket on the same line, but after seeing the style used at my recent job for a while I converted. Old habits die hard, but I think I like the brace on its own line. It does just match better.