A Programming Question
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
I have a bail-out return statement at the beginning of a function if there are immediate problems (bad input, object not setup etc), and I'll often do the same with loops (use a
continueif it's immediately apparant that the loop should skip this particular iteration. And sometimes I throw in a random return path in the middle of a function because I'm evil. cheers, Chris MaunderCodeProject.com : C++ MVP
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
...sorta. Non-trivial methods generally start by checking the validity of any parameters, the state of the class, etc. If any of these "sanity checks" fail, i immediately return an error. After that, i try and keep all returns at the end of the method, regardless of where the value originates. I have no qualms about using
breakorcontinuein loops though - if a loop gets to where such things would make the code hard to follow, chances are it's a good time to refactor it anyway.You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...
-
Personally I use
goto's for difficult flow control, screw style! Just get it working the best it can be! [update] counted 6 goto's in the C# part of xacc :). Here's a nice example://some code before
foreach (MRUFile mru in recentfiles)
{
if (mru.filename == filename)
{
mru.Update();
goto DONE;
}
}
recentfiles.Add( new MRUFile(filename));DONE:
//some code afterNow I can already hear the cursing, but any other form of flow control, you need 1 or more variables to carry some (unneeded, and extra) state, and make the whole thing much less readable. :-D [update] xacc.ide-0.1-rc4 released! Download and screenshots -- modified at 16:19 Monday 14th November, 2005
Maybe I should put
g*toin the Bad Words filter list. cheers, Chris MaunderCodeProject.com : C++ MVP
-
Really :omg: Not even:
Something* SearchForSomething(...) { Something* pSomethingTested; Something* pSomethingFound = NULL; while( !pSomethingFound ){ pSomethingTested = GetPointertoWhatever(); if( pSomethingTest matches my search criteria ){ pSomethingFound = pSomethingTested; } } return pSomethingFound; }It really IS that simple and straightforward :->Actually, in strictest terms, your test
whiel( !pSomethingfound )violates "decent" coding standards. Only booleans should be tested in this manner. A pointer should be explicitly tested against 0 (or NULL, if defined). Just my itty 2 cents ;) Bob Ciora -
...sorta. Non-trivial methods generally start by checking the validity of any parameters, the state of the class, etc. If any of these "sanity checks" fail, i immediately return an error. After that, i try and keep all returns at the end of the method, regardless of where the value originates. I have no qualms about using
breakorcontinuein loops though - if a loop gets to where such things would make the code hard to follow, chances are it's a good time to refactor it anyway.You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...
I do the same thing. Also, continues help reduce nesting in loops, making the code more readable. I validate input at the top of loops and continue out if invalid, just like how I validate arguments at the top of a function and return out if invalid.
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
I try to follow this ideal, but I won't write convoluted code to make it happen, for example, I wouldn't write something that sets i and j to values that will break the outer loops. Christian Graus - Microsoft MVP - C++
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
Marc Clifton wrote:
There's a philosophy about always having one exit point in a method
Yes, that's exactly what it is, a "philosophy". And your last paragraph explains very well why it is an outdated one. The whole thing started back in the days when programming meant either Fortran or assembler. And the people that frown upon multiple return points don't like break statements in loops either, they say they are just fake go-to statements. I think code clarity is always a lot more important than any other philosophy. Try this test: add another 20 lines to your function, 2 more preconditions (oyOyOy and oops :-) ) and at least one try-catch and then write the code both ways: with preconditions and with early return. Then get one of your coleagues to have a look at your code and try to understand it. See which version was best. If you need an "excuse", look at it as "programming by contract": if the preconditions are not met, you don't even start processing. OGR
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
Please wait while I consult with my Rice Krispies. :~ Where's the milk...? :-D RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
Style and phylosophy be damned. The most important things in programming is to be correct, consise and clear. The whole notion of having one exit point in a function was an axiom of good ASSEMBLY and MACHINE language programming. Which "some" people insist on following in higher level languages. The fact is, all functions in higher level languages really do only have one exit point (did you know you can put a breakpoint on the closing brace '}' of a function? try it, you'll like it - and it proves my point). So having multiple return statements is not a problem. Neither is using continue, goto or break. It all depends on the situation.
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
Marc Clifton wrote:
First off, do you prescribe to that philosophy?
No, since early exit helps avoiding deeply nested structures, which I consider worse. Though I frequently have comments that indicater under which "final" condsition the execution arrives here. I try to keep things consistent per function - usuallz early exit on failure.
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen -
Nishant Sivakumar wrote:
*ahem*
You realize you're the first one to catch that. :-D Good call! I may harrass people about spelling errors, but those are nothing compared to a bad programming example error! Marc VS2005 Tips & Tricks -- contributions welcome!
At least you didn't embed a "hello world" in the example.:doh: "...a photo album is like Life, but flat and stuck to pages." - Shog9
-
Really, this is a programming question. There's a philosophy about always having one exit point in a method, so, you'll typically see something like this: void Foo() { MyRet ret=null; if (blah) { ret=bar; } return ret; } Or, if it's a for loop, ret will be assigned followed by a break. First off, do you prescribe to that philosophy? Do you do so religiously? If so, what do you do when you have several nested loops, and you need to break out of the innermost one and return the value? :) Marc VS2005 Tips & Tricks -- contributions welcome!
I tend to have one return at the bottom. Because many years ago I had a compiler that actually dropped through one of the return statements and executed the follwing code instead! It was real fun finding that one!
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for - in order to get to the job you need to pay for the clothes and the car, and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman