ID:173679
 Nov 30 2003, 4:17 pm
|
|
Would everything just be much simpler if I end all if and else commands with return?
| |
DiZzyBonne wrote:
Oh, but I meant at the END of an if or an else. Doesn't matter. At the end of one is the same as putting it inside both the if() and the else parts. It's not always appropriate; don't just assume it is. Lummox JR | |
Do you ALWAYS want the proc to end at the end of them? Look at this code.
verb/eat(obj/o as obj in view(1)) if (o.flavor == "bad") usr << "It tastes terrible." oview(usr) << "[usr] makes a face." else usr << "It tastes wonderful!" oview(usr) << "[usr] licks \his lips." usr.sustenance += o.nutrition Why on earth would you wanna put a return at the end of the if and the else? You'd have to copy the usr.sustenance code and add it in twice, once for each branch! If there wasn't any code that was common between the two, then a return wouldn't hurt... but how do you imagine it would help? I think your question reveals a very common problem... people not actually understanding what it is they're working with. You've obviously got some kind of misapprehension about either if/elses, or returns. Why don't you explain how you thought this would "simplify" things so we can clear it up? | |
Hedgemistress wrote:
Do you ALWAYS want the proc to end at the end of them? Look at this code. What if it was: verb/eat(obj/o as obj in view(1)) if (o.flavor == "bad") usr << "It tastes terrible." oview(usr) << "[usr] makes a face." return else usr << "It tastes wonderful!" oview(usr) << "[usr] licks \his lips." usr.sustenance += o.nutrition I assume that would work, correct? | |
DiZzyBonne wrote:
What if it was: Depends what you mean by "work". It wouldn't work the way Lexy's example would; bad-flavored food would have no nutritional value, which runs strongly against reality. So to assume her example was the correct behavior, then your modification would have broken it. Lummox JR | |
If the goal is to make it so that only good tasting food has any nutrition... my point, though, was that both foods would have nutrition and you only want to use return if there's NO code that should happen for both cases. The return is still a wasted line... if your goal is to make it so that only good food gives nutrition, you would do this: if (o.flavor == "bad") usr << "It tastes terrible." oview(usr) << "[usr] makes a face." else usr << "It tastes wonderful!" oview(usr) << "[usr] licks \his lips." usr.sustenance += o.nutrition One less line, and does the same thing. The ONLY time that you would want to use a return is if a) you've got more than two cases (if, else if, else if, else...), almost all the cases share some code (which you'd put after the ifs and elses so you don't have to repeat each time), but one of the branches needs to stop executing before it gets there. if (flavor == "good") usr << "It tastes good!" else if (flavor == "putrid") usr << "It tastes not so good!" else if (flavor == "cardboard") usr << "It tastes like cardboard!" return else usr << "It tastes poorly defined!" sustenance += nutrition In this case, if you eat food that tastes like cardboard, you get no nutrition but if you eat food that tastes good, putrid, or anything else, you get nutrition. If you want to get sustenance from everything you eat, you wouldn't have a return on any of them. Again, it's a simple matter of stopping and thinking. return ENDS the procedure completely. If you think you maybe should use it, stop and think, "How is it different if I stop the proc here or if I don't?" It almost sounds like you wanna use return to "simplify" if/else trees 'cause you've got problems with sloppy indenting. Trying to fix a concept you don't quite understand by throwing in another concept you don't quite understand is just asking for trouble. | |
Really quick, is:
else if(good == 1) the same thing as: else thanx | |
What Lummox said, although if he hadn't answered first, I would've told you to figure it out for yourself, run through the code in your head and tell yourself what, if anything, would be different the one way from the other.
| |
It's simple as it is. if and else statements end themselves after they've found the proper definitions and reach the end of the block. Adding return is actually more work. Think of how much energy you'd save if you didn't add an extra six characters at the end of each if/else block. I rarely use else though; I use something similar to the code that follows, in which case it's required.
mob | |
Your post misses on multiple key points and thereby threatens to confuse the issue further. In your example, return is not required, you could have used else and saved two keystrokes. Also, if and else statements ending themselves doesn't make return redundant, since return ends the proc as a whole.
That's the question that should be asked: "Do I want the whole proc to end here?" | |
No, because it's not appropriate all the time. If an if/else block is followed by more code, that code won't run if you use return first.
Lummox JR