This question already has answers here:
Is returning early from a function more elegant than an if statement?
(14 answers)
Closed 7 years ago.
I have been referring my new company's code, where I found the code was not wrapped around IF and ELSE so was little bit confusing in flow. For example:
if(user_is_registered)
{
// You are already registered.
//exit
}
//New user's registration code goes here
While my last company was following the other way i.e. :
if(user_is_registered)
{
// You are already registered.
}
else
{
//New user's registration code goes here
}
Like every fresher I am confused which is the best practice to follow with legitimate reasons. Please enlighten me. I tried to find out answers for the same, but could not get. Some of answers are there in which some experts are supporting way 1 some are supporting way 2. Please also suggest me other refs if available. Thank you.
It may well have been a decision made in order to avoid nesting. In your example it's not immediately apparent, but if there are further IF, LOOP, etc. statements further down in the registration logic, then nesting start to occur.
As a general rule nesting should be avoided and refactored away as it hinders comprehension and is often indicative that the method is doing too much.
e.g.
if ( user_is_registered )
{
// do something & return
}
else
{
// do something else
if ( some_other_condition )
{
// do another thing
while (something_is_not_true)
{
// loopy things
}
}
}
When you use an else you're building logic that is very explicit. By having separate if statements you can apply multiple blocks of rules on given conditions.
It could be that the object being compared meets multiple requirements, so Else would not be any good.
Take this example:
var x = 10;
if (x < 11){
// do something
// - this gets hit
}else{
// do something else
}
// perhaps i want to have multiple conditions that x meets..
if (x < 11){
// do something
// - this gets hit
}
if {x == 10){
// do something
// - this gets hit - provided the if before didn't make changes to X
}
if (x != 10){
// do something - this won't be hit, unless a previous if made changes to x
}
Now - when you take your particular example, //New user's registration code goes here in your first block will ALWAYS fire if there wasn't a way to exit out of the method, as there is in your if. In your 2nd block it only fires if the if doesn't match.
Personally, I would wrap in the if/else, in this case and be explicit with the code and the intent.
If you want a block of code to be executed only if the condition in if statement fails, then add the block as else part of the if statement. The statements are exclusive. Only the if block or else block is executed not both.
If you want the block of code to be always executed, include the block after if statement. The block is always executed.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Whenever I need to break out from a for(unsigned int i=0;i<bound;++i) expression in C++, I simply set the index variable i=bound, the same way as described in this answer. I tend to avoid the break statement because, honestly, I have no good understanding of what it actually does.
Compare the two instructions:
for(unsigned int i=0;i<bound;++i) {
if (I need a break) {
break;
}
}
and
for(unsigned int i=0;i<bound;++i) {
if (I need a break) {
i=bound;
}
}
I speculate that the second method does one extra variable set and then one extra comparison between i and bound, so it looks more expensive, from performance point of view. The question is then is it cheaper to call break, then doing these two tests? Are the compiled binaries any different? Is there any instance, where the second method breaks, or can I safely choose either of these two alternatives?
Related: Does `break` work only for `for`, `while`, `do-while`, `switch' and for `if` statements?
Breaking out of a loop without a break statement [C]
Using break will be more future proof and more logical.
Consider the following example,
for (i = 0; i < NUM_OF_ELEMENTS; i++)
{
if(data[i] == expected_item)
break;
}
printf("\n Element %d is at index %d\n", expected_item, i);
But the second method won't be useful here.
There are three main technical differences that come to mind:
as other have stated, if your index variable is not confined to the for scope break leaves it intact, while your method destroys its content; when you are searching e.g. an array with break the code is more concise (you don't have to keep an extra variable to write down where you stopped);
break quits the loop immediately; your method requires you to execute the rest of the body. Of course you can always write:
for(int i=0; i<n; ++i) {
if(...) {
i=n;
} else {
rest of the loop body
}
}
but it adds visual and logical clutter to your loop;
break is almost surely going to be translated to a simple jmp to the instruction just following the loop (although, if you have block-scoped variables with a destructor the situation may be more complicated); your solution is not necessarily recognized by the compiler as equivalent.
You can actually see it here that gcc goes all the way to generate the code that moves n into i, while in the second case it jumps straight out of the loop.
On the stylistic side:
I find "your way" to be overly complicated and not idiomatic - if I encountered it in real code I would ask myself "why didn't he just use a break?", and then check twice to make sure that it's not like I'm missing some side effect and that the intent was actually just to jump out of the loop;
as other said, there's some risk of your inner assignment to go out of sync with the actual loop condition;
it doesn't scale when the loop condition becomes more complicated than a simple range check, both on the logic side (if the loop condition is complicated then tricking it can become more complicated) and on the performance side (if the loop condition is expensive and you already know you want to exit you don't want to check it again); this too can be circumvented by adding an extra variable (which is typically done in languages that lack break), but that's again extra distractions from what your algorithm is actually doing;
it doesn't work at all with range-based loops.
I prefer break; because it leaves the loop variable intact.
I frequently use this form while searching for something:
int i;
for(i=0; i<list.size(); ++i)
{
if (list[i] == target) // I found what I'm looking for!
{
break; // Stop searching by ending the loop.
}
}
if (i == list.size() ) // I still haven't found what I'm looking for -U2
{
// Not found.
}
else
{
// Do work with list[i].
}
Are the compiled binaries different?
Almost certainly yes. (although an optimizer may recognize your pattern, and reduce them to nearly the same)
The break; statement will likely be an assembly "jump" statement to jump to the next instruction outside the list, while leaving the control variable unchanged.
Assigning the variable (in non-optimized code) will result in an assignment to the control variable, a test of that variable, and then a resulting jump to end the loop.
As others have mentioned, assigning the variable to its final value is less future-proof, in case your loop condition changes in the future.
In general, when you say:
"I have no good understanding of what it actually does. (so I use a workaround)",
I respond with:
"Take the time to learn what it does! A main aspect of your job as a programmer is to learn stuff."
Using break to do this is idiomatic and should be the default, unless for some reason the rather obfuscatory alternative serves to set the stage for logic below. Even then I'd prefer to do the variable setup after the loop exits, moving that setting closer to its usage for clarity.
I cannot conceive of a scenario where the performance matters enough to worry about it. Maybe a more convoluted example would demonstrate that. As noted the answer for that is almost always 'measure, then tune'.
In adition to the break statement to exit a for or [do] while loop, the use of goto is permitted to break out nested loops, e.g.:
for (i=0; i<k; i++) {
for (j=0; j<l; j++) {
if (someCondition) {
goto end_i;
}
}
}
end_i:
I am a novice programmer and was in lecture one evening, we were studying the "if,else" coding section from my professor and I was curious about an aspect of it. What I was curious about was if we have a bunch of nested if,else's in our program, is it just bad coding style to end an if,else with an "else,if" line of code instead of if "x", else "y"? For example,
if "x"
else if "y"
else if "z"
end
compared to
if "x"
else if "y"
else "z"
end
It would still run the program without an error, but are there consequences later on other than having bad programming style?
Behind the curtain JS dont really have else if, all it is doing is generating another if statement when parsed.
e.g:
if(foo){
} else if (baz){
}
becomes
if (foo){
} else {
if (baz){
}
}
So the reason for using another else if in the end instead of else is when you want to control the else statement as-well and not just pass to that case everything else that don't fit in your first condition... (In order to control the else condition and filter it to the necessary items only)
if you do have a really long statement with a lot of else-if conditions you should consider using switch statement instead.
It all depends on what you are looking to do. The former example makes sure that all IF requirements are met. There would be instances that none of the IFs get hit in this case.
In the latter example however, ELSE "Z" would get hit for sure if all above IFs fail. This would be useful if you are assigning a variable within your IFs - your variable will definitely have a value at the end of the IF statement. If it was as in the first example, the variable will be null and might result in a null error if you try to use it later.
If there are a lot of if-thens, I would checkout the case/switch statement as well, as it is more neater to implement.
Also, remember to comment your code well - especially explaining what all the nested IFs are doing.
I read some legacy code:
if ( 1 || !Foo() )
Is there any seen reason why not to write:
if ( !Foo() )
The two are not the same. The first will never evaluate Foo() because the 1 short-circuits the ||.
Why it's done - probably someone wanted to force entry in the then branch for debugging purposes and left it there. It could also be that this was written before source control, so they didn't want the code to be lost, rather just bypassed for now.
if (1 || !Foo() ) will be always satisfied. !Foo() will not even be reached because of short-circuits evaluation.
This happens when you want to make sure that the code below the if will be executed, but you don't want to remove the real condition in it, probably for debug purposes.
Additional information that might help you:
if(a && b) - if a is false, b won't be checked.
if(a && b) - if a is true, b will be checked, because if it's false, the expression will be false.
if(a || b) - if a is true, b won't be checked, because this is true anyway.
if(a || b) - if a is false, b will be checked, because if b is true then it'll be true.
It's highly recommended to have a macro for this purpose, say DEBUG_ON 1, that will make it easier to understand what the programmer means, and not to have magic numbers in the code (Thanks #grigeshchauhan).
1 || condition
is always true, regardless whether the condition is true or not. In this case, the condition is never even being evaluated. The following code:
int c = 5;
if (1 || c++){}
printf("%d", c);
outputs 5 since c is never incremented, however if you changed 1 to 0, the c++ would be actually called, making the output 6.
A usual practical usage of this is in the situation when you want to test some piece of code that is being invoked when the condition that evaluates to true only seldom is met:
if (1 || condition ) {
// code I want to test
}
This way condition will never be evaluated and therefore // code I want to test always invoked. However it is definitely not the same as:
if (condition) { ...
which is a statement where condition will actually be evaluated (and in your case Foo will be called)
The question was answered properly - the difference is the right side of the or operation is short-circuited, suggesting this is debug code to force entry into the if block.
But in the interest of best practices, at least my rough stab at a best practice, I'd suggest alternatives, in order of increasing preference (best is last):
note: noticed after I coded examples this was a C++ question, examples are C#. Hopefully you can translate. If anyone needs me to, just post a comment.
In-line comment:
if (1 /*condition*/) //temporary debug
Out-of-line comment:
//if(condition)
if(true) //temporary debug
Name-Indicative Function
//in some general-use container
bool ForceConditionForDebug(bool forcedResult, string IgnoredResult)
{
#if DEBUG
Debug.WriteLine(
string.Format(
"Conditional {0} forced to {1} for debug purposes",
IgnoredResult,
forcedResult));
return forcedResult;
#else
#if ALLOW_DEBUG_CODE_IN_RELEASE
return forcedResult;
#else
throw new ApplicationException("Debug code detected in release mode");
#endif
#endif
}
//Where used
if(ForceConditionForDebug(true, "condition"))...
//Our case
if(ForceConditionForDebug(true, "!Foo()"))...
And if you wanted a really robust solution, you could add a repository rule to source control to reject any checked in code that called ForceConditionForDebug. This code should never have been written that way because it obviously doesn't communicate intent. It never should have been checked in (or have been allowed to be checked in) (source control? peer review?) And it should definitely never be allowed to execute in production in its current form.
Recently we found a "good way" to comment out lines of code by using continue:
for(int i=0; i<MAX_NUM; i++){
....
.... //--> about 30 lines of code
continue;
....//--> there is about 30 lines of code after continue
....
}
I scratch my head by asking why the previous developer put the continue keyword inside the intensive loop. Most probably is he/she feel it's easier to put a "continue" keyword instead of removing all the unwanted code...
It trigger me another question, by looking at below scenario:
Scenario A:
for(int i=0; i<MAX_NUM; i++){
....
if(bFlag)
continue;
....//--> there is about 100 lines of code after continue
....
}
Scenario B:
for(int i=0; i<MAX_NUM; i++){
....
if(!bFlag){
....//--> there is about 100 lines of code after continue
....
}
}
Which do you think is the best? Why?
How about break keyword?
Using continue in this case reduces nesting greatly and often makes code more readable.
For example:
for(...) {
if( condition1 ) {
Object* pointer = getObject();
if( pointer != 0 ) {
ObjectProperty* property = pointer->GetProperty();
if( property != 0 ) {
///blahblahblah...
}
}
}
becomes just
for(...) {
if( !condition1 ) {
continue;
}
Object* pointer = getObject();
if( pointer == 0 ) {
continue;
}
ObjectProperty* property = pointer->GetProperty();
if( property == 0 ) {
continue;
}
///blahblahblah...
}
You see - code becomes linear instead of nested.
You might also find answers to this closely related question helpful.
For your first question, it may be a way of skipping the code without commenting it out or deleting it. I wouldn't recommend doing this. If you don't want your code to be executed, don't precede it with a continue/break/return, as this will raise confusion when you/others are reviewing the code and may be seen as a bug.
As for your second question, they are basically identical (depends on assembly output) performance wise, and greatly depends on design. It depends on the way you want the readers of the code to "translate" it into english, as most do when reading back code.
So, the first example may read "Do blah, blah, blah. If (expression), continue on to the next iteration."
While the second may read "Do blah, blah, blah. If (expression), do blah, blah, blah"
So, using continue of an if statement may undermine the importance of the code that follows it.
In my opinion, I would prefer the continue if I could, because it would reduce nesting.
I hate comment out unused code. What I did is that,
I remove them completely and then check-in into version control.
Who still need to comment out unused code after the invention of source code control?
That "comment" use of continue is about as abusive as a goto :-). It's so easy to put an #if 0/#endif or /*...*/, and many editors will then colour-code the commented code so it's immediately obvious that it's not in use. (I sometimes like e.g. #ifdef USE_OLD_VERSION_WITH_LINEAR_SEARCH so I know what's left there, given it's immediately obvious to me that I'd never have such a stupid macro name if I actually expected someone to define it during the compile... guess I'd have to explain that to the team if I shared the code in that state though.) Other answers point out source control systems allow you to simply remove the commented code, and while that's my practice before commit - there's often a "working" stage where you want it around for maximally convenient cross-reference, copy-paste etc..
For scenarios: practically, it doesn't matter which one you use unless your project has a consistent approach that you need to fit in with, so I suggest using whichever seems more readable/expressive in the circumstances. In longer code blocks, a single continue may be less visible and hence less intuitive, while a group of them - or many scattered throughout the loop - are harder to miss. Overly nested code can get ugly too. So choose either if unsure then change it if the alternative starts to look appealing.
They communicate subtly different information to the reader too: continue means "hey, rule out all these circumstances and then look at the code below", whereas the if block means you have to "push" a context but still have them all in your mind as you try to understand the rest of the loop internals (here, only to find the if immediately followed by the loop termination, so all that mental effort was wasted. Countering this, continue statements tend to trigger a mental check to ensure all necessary steps have been completed before the next loop iteration - that it's all just as valid as whatever follows might be, and if someone say adds an extra increment or debug statement at the bottom of the loop then they have to know there are continue statements they may also want to handle.
You may even decide which to use based on how trivial the test is, much as some programmers will use early return statements for exceptional error conditions but will use a "result" variable and structured programming for anticipated flows. It can all get messy - programming has to be at least as complex as the problems - your job is to make it minimally messier / more-complex than that.
To be productive, it's important to remember "Don't sweat the small stuff", but in IT it can be a right pain learning what's small :-).
Aside: you may find it useful to do some background reading on the pros/cons of structured programming, which involves single entry/exit points, gotos etc..
I agree with other answerers that the first use of continue is BAD. Unused code should be removed (should you still need it later, you can always find it from your SCM - you do use an SCM, right? :-)
For the second, some answers have emphasized readability, but I miss one important thing: IMO the first move should be to extract that 100 lines of code into one or more separate methods. After that, the loop becomes much shorter and simpler, and the flow of execution becomes obvious. If I can extract the code into a single method, I personally prefer an if:
for(int i=0; i<MAX_NUM; i++){
....
if(!bFlag){
doIntricateCalculation(...);
}
}
But a continue would be almost equally fine to me. In fact, if there are multiple continues / returns / breaks within that 100 lines of code, it is impossible to extract it into a single method, so then the refactoring might end up with a series of continues and method calls:
for(int i=0; i<MAX_NUM; i++){
....
if(bFlag){
continue;
}
SomeClass* someObject = doIntricateCalculation(...);
if(!someObject){
continue;
}
SomeOtherClass* otherObject = doAnotherIntricateCalculation(someObject);
if(!otherObject){
continue;
}
// blah blah
}
continue is useful in a high complexity for loop. It's bad practice to use it to comment out the remaining code of a loop even for temporary debugging since people tends to forget...
Think on readability first, which is what is going to make your code more maintainable. Using a continue statement is clear to the user: under this condition there is nothing else I can/want to do with this element, forget about it and try the next one. On the other hand, the if is only telling that the next block of code does not apply to those for which the condition is not met, but if the block is big enough, you might not know whether there is actually any further code that will apply to this particular element.
I tend to prefer the continue over the if for this particular reason. It more explicitly states the intent.
So I have some C++ code for back-tracking nodes in a BFS algorithm. It looks a little like this:
typedef std::map<int> MapType;
bool IsValuePresent(const MapType& myMap, int beginVal, int searchVal)
{
int current_val = beginVal;
while (true)
{
if (current_val == searchVal)
return true;
MapType::iterator it = myMap.find(current_val);
assert(current_val != myMap.end());
if (current_val == it->second) // end of the line
return false;
current_val = it->second;
}
}
However, the while (true) seems... suspicious to me. I know this code works, and logically I know it should work. However, I can't shake the feeling that there should be some condition in the while, but really the only possible one is to use a bool variable just to say if it's done. Should I stop worrying? Or is this really bad form.
EDIT: Thanks to all for noticing that there is a way to get around this. However, I would still like to know if there are other valid cases.
I believe that there are cases where it's fine for seemingly infinite loops to exist. However this does not appear to be one of them. It seems like you could just as easily write the code as follows
while (current_val != searchVal ) {
MapType::iterator it = myMap.find(current_val);
assert(current_val != myMap.end());
if (current_val == it->second) // end of the line
return false;
current_val = it->second
}
return true;
This seems to express the true intent of the loop better
My two cents is: code should be self-documenting. That is, when given a piece of code, I'd rather be able to look and tell the programmer's intent then have to read comments or trudge through the surrounding code. When I read:
while(true)
That tells me the programmer wanted an infinite loop; that the end condition couldn't be specified. This is the programmers intent in some circumstances; a server loop for instance, and that is when it should be used.
In the above code, the loop isn't meant to be forever, it has a clear end condition, and in order to be semantically clear, as others have pointed out:
while (currentVal != searchVal)
works, so the while(true) is clearly inferior and should be avoided in this instance.
There are times and places for infinite loops - I am not convinced this is one of them. On the other hand, it is far from being an egregious problem here.
while (currentVal != searchVal)
{
...
}
return true;
One place to use them is when the process is truly indefinite - a daemon process with a monitor loop that won't terminate.
There are situations where a construct like this makes sense:
The break condition is computed within the loop
There are more breaking conditions and they are all equally important
You really want an endless loop ;) ..
I agree with the other answers that there's no need for an infinite loop in this case.
However, another point might be that when you do have an infinite loop, for(;;) might be a better way to express it. Some compilers generate warnings for while(true) (condition always evaluates to false), and your intent is less clear because it looks like any other loop. Perhaps it used to say while (x == true), and you accidentally removed the x instead of the true. for(;;) says pretty clearly that this is intended to be an infinite loop. Or perhaps you intended to write something like while(t), but Intellisense in your IDE kicked in and decided to autocomplete to true.
for(;;) on the other hand, isn't something you'd ever type accidentally. (and it's easier to search for. while(true) could also be written as while(1))
Neither version is wrong, but for(;;) might be more intuitive because there is no loop condition.
while(true) is used in games for the main game loop - games continually read player input, process interactions between objects and paint your screen, then repeat. This loop continues infinitely until some other action breaks out of that loop (quitting the game, finishing the level).
I tried to quickly find this main loop in the Quake 1 source code for you, but there were at least 50 occurrences of 'while(1)', as well as some written as 'for(;;)', and I wasn't immediately sure which one was the main game loop.
Although I've done them before, I'd vote for always trying to go for the clearer solution by using something readable, which would generally include a valid expression in the while loop--otherwise you're scanning code to look for the break.
I'm not really terrified of them or anything, but I know some people are.
Well, a comment saying that it is not really an infinite loop would help:
while (true) // Not really an infinite loop! Guaranteed to return.
I do agree that it should have a condition, but this is okay in some situations (and it's not always possible or easy to make a condition).
Stop worrying. This is not bad form if it helps to simplify the logic of the code and improve maintainability and readability. Worthwhile though to document in comments on the expected exit conditions and on why the algorithm will not slip into an infinite loop.
Well, yes, but the two pages of code you have to write if you don't want your main loop to be something like while(true) is even worse form.
It is not uncommon to find infinite loops in embedded systems code - often surrounding finite state machines, checking peripheral chips and devices, etc.
I love infinite loops as the outside control structure of a finite state machine. It's effectively a structured goto:
for (;;) {
int c = ReadInput();
if (c == EOF)
return kEOF;
switch (state) {
case inNumber: state = HandleNumber(c); break;
case inToken: state = HandleToken(c); break;
case inWhiteSpace: state = HandleWhiteSpace(c);
default:
state = inError;
break;
}
if (state == inError) ThrowError();
}