-
Good programming Style
Hello,
I am developing a routine which has mutiple returns. Some of the returns are in deep nested loops.
Is it bad programming practice to return from deep nested loops? If yes, Is there any way to avoid that?
I am trying structure my coding, like on all succcessful if condition do what it needs to and all else will fall to one return. But for nested return, I do not have any trick.
Any other idea or pointers will be greately appreciated...
Thanks,
Juganoo
-
i usually try to avoid multiple return statements. they can get confusing.. i would make a variable (int returnValue, for example) that holds what value you want to return, then just return that at the end. if there's some code where this wouldn't be possible (or atleast not very easy) post it, and there may be a easier/clearer way (nested loops can get pretty messy, and i try to avoid them.. that's just me though).
-
Returning from nested loops may be your best bet. Breaking from multiple blocks is a pain. Your options really are returning or using something like a goto to do the jump for you. I'd personally use the return statement before I'd resort to a goto.
It's not confusing as far as code goes to see that the function is supposed to end at scenario X in your loops.
Still, most things can be written with few return statements. The main thing I keep in mind is how clean the code is. Is it easily understood? That's the main point I keep in mind when programming. Make your code clearly readable and easily understood and the rest pretty much takes care of itself.
Quzah.
-
Like Quzah is saying sometimes it is best.
Example
Code:
int ContainsChar(const char *s, char c) {
for(;*s++;)
if(*s == c)
return 1;
return 0;
}
It is more optimized than having only a single return statement. It is also not at all hard to follow the flow of this code. Anyone reading the code can clearly see that a zero return is a default whereas one has some meaning.
-
what about having exits placed within nested functions/child threads or nested loops.
should the error be handed back to the main function/thread and the program terminated there, or is terminating within the function/child thread ok?
-
This is one area where I prefer c++ over c. SEH is easier to deal with there with their exception throwing.
In c (I'm a newbie too) I've used 4 methods that I don't really like too much so I'm all eyes if any one has ideas.
1) Exiting directly from a not too deeply dested function where the meaning is totally clear. Like in user input validation... you know where you blame the user & refuse to go on with their nonsense if they have "that" kind of attitude.
2) Using a global error flag. I don't like this one much so I'll stop here.
3) I've been trying to pass structure addresses to functions with an error code in them that can be check & handled where I like. It seems to be used a sometimes in the *nix libs. But I've dropped this one in favor of....
4) Same stucture as #3 but I return an error code so it's not in the structure directly. It seems to be the method used in most of the *nixie libs so I'm currently using that method & sticking with it. The handler has to decide what to do; the programming equivalant of passing the buck.
hth