|
Where do you put the opening brace? Being "raised" on C, I personally hate the Java convention of putting the opening brace on the same line as the condition.
In fact I have started to
if (condition)
{
doStuff();
}in our Java code. There's nothing to be gained by cramming everything together as close as possible.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I prefer to do it like that too, but if it the rest of the code is already in the IF line... well... I continue to be consistent.
If it is something I start on my own... 100% with markers, in single lines AND in the same indentation as the if and not as the code executed when condition met. I mean:
if (condition)
{
doStuff();
}
AND NOT:
if (condition)
{
doStuff();
}
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
There was an interesting article about always using multi line, always using braces and the position of the braces to allow for the best automated merging in SCM systems.
|
|
|
|
|
Yupe, totally agree. More human readable, easy for maintenance, less bug.
|
|
|
|
|
If there is only 1 statement in the if/for/while-block, then no markers, but the statement in the block is written on a separate line, in order to simplify putting a breakpoint on that line.
Easy to put a breakpoint that only goes off if the condition is satisfied:
if (myCondition)
doSomething()
Harder to put a breakpoint (I don't mind jumping into disassembly to find the exact call, but my colleagues don't like it):
if (myCondition) doSomething()
Of course if there is only 1 caller of doSomething(), then you can just put a breakpoint in that function, but what if that function is called a zillion times?
|
|
|
|
|
I can understand your point but having one statement in a separate line after an if as you post in your first snippet is the easiest way to look for problems if you ever add something in that IF.
if (Validation)
dosomething();
versus
if (Validation)
dosomethingnew();
dosomething();
That's why, if I go in a second line I always use the block markers even for only one statement:
if (Validation)
{
dosomething();
}
or
if (Validation) {
dosomething();
}
I actually prefer to put the marker in a new line (#3) instead of at the end of the line (#4) but this is something that I don't really care and I keep consistent with the rest of the code.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's indeed a risk, but in practice I never encountered this problem. Developers are (or should be) smart enough to realize that if they add a statement to the IF-block, they should add curly braces.
So in theory a risk, in practice not so much.
|
|
|
|
|
Patrick Van Cauteren wrote: Developers are (or should be) smart enough to realize that if they add a statement to the IF-block,
It has nothing to do with intelligence. One can be in stress, have a bad day, be tired and many other factors that might influence the probability of doing such an error.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
with "lines", I use languages with statements.
|
|
|
|
|
You must be fun at parties
|
|
|
|
|
Statements made by parties are sometimes rather difficult to parse consistently.
|
|
|
|
|
recommends the use of block markers even for a single line of code being enclosed.
|
|
|
|
|
The anal retentive, ever with us.
|
|
|
|
|
But do they recommend markers for a single line of code not being enclosed?
|
|
|
|
|
As a general practice I use block markers. However this also depends on established coding standards as well, as some companies require them while others don't.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
IMHO, I prefer:
if (!whatever) return 'Something';
But if i need to put more code in a single line:
if (!whatever) {
return auxObj.toResult( data => {
} );
}
|
|
|
|
|
...nearly always.
If it's
if (!validity check) return errorcode;
Or
if (!validity check) throw somekindoferror;
then I don't.
And I don't care that you think there should be only one exit from a function: I do validity checking at the top of the function, report errors where I can, and exit immediately. That way the rest of the function is clean and using clean data.
Just makes things more obvious IMO.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
+1
I like validity checks at the beginning too.
But... if the validation is somewhere in the middle, then I set an "not OK" and only return at the end.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
There should be a single exit from an algorithm. Functions are not algorithms, they are implementations of them, consisting of many different algorithms, such as input / error validation.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
But doing that, you miss out on 843 levels of indentation!
veni bibi saltavi
|
|
|
|
|
And that is what widescreen monitors were invented for! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
In my student days, one of the ACM periodicals (it might have been one of the SIG newsletters; I don't remember) had an article with the title 'The rightward migration of source code'. The problem became very apparent very soon after the introduction of 'structured programming', until programmers learned to distinguish between 'use' and 'overuse' of the concept.
|
|
|
|
|
OriginalGriff wrote: If it's
if (!validity check) return errorcode;</blockquote> Sure, but I burned my fingers on that one: It took me a day of debugging to realize the return was not effectuated until after the execution of the 'finally' clause in the enclosing exception block.
(The effect of the 'finally' clause taking for granted that all structures had been successfully updated, didn't manifest until far later in the execution order; that's why the problem took so long to find.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
