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 always have one exit point at the end of the method and never use break in loops. It's akin to goto in my mind - another tool of the devil. I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise. Cheers, Drew.
-
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 always think that this is what puts the "engineering" in "Software Engineering". To directly answer your question, yes, I think it's a good idea, but no, I don't always do it. It depends on circumstances. To summarise: The point about having rules is so that you'll think before you break them.
-
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!
If you methods are small enough as they should be then there should be no issue if you exit a method inside a loop. It usually cleans up the code and makes it easier to read. On the other hand, if you have a large method or dealing with a bunch of exception handling, it is probably best to keep one return as long as it does not clutter the code too much. Same goes with the old evil Goto. I have not used it in years, but there are those times that it just makes sense instead of ugly nestings and checking. So, for the most part, I usually have only one return, but at times I will use a nested exit where it would cause for cluttered or plain ugly code to do otherwise. Rocky <>< Latest Post: Time for change! Blog: www.RockyMoore.com/TheCoder/[^]
-
I always have one exit point at the end of the method and never use break in loops. It's akin to goto in my mind - another tool of the devil. I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise. Cheers, Drew.
Drew Stainton wrote:
never use break in loops
What, never? Doesn't that make any linear search you do (for example finding a particular element in an array) a bit inefficient? Once you've found what you're looking for, surely you don't process the rest of the elements anyway?
-
Drew Stainton wrote:
never use break in loops
What, never? Doesn't that make any linear search you do (for example finding a particular element in an array) a bit inefficient? Once you've found what you're looking for, surely you don't process the rest of the elements anyway?
Graham Bradshaw wrote:
Once you've found what you're looking for, surely you don't process the rest of the elements anyway?
No, as per what he wrote, he puts a condition in the outer loops that checks if the return var has been assigned. So the outer loops all exit, bam-bam-bam. Pretty slick! Marc VS2005 Tips & Tricks -- contributions welcome!
-
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:
void Foo()
Marc Clifton wrote:
return ret;
*ahem* Nish :-D
-
I always have one exit point at the end of the method and never use break in loops. It's akin to goto in my mind - another tool of the devil. I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise. Cheers, Drew.
Drew Stainton wrote:
I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise.
Ah, very nifty! 20 years of programming, and I never thought of that. In fact, I don't think I've even ever seen it in other people's code. :doh: Marc VS2005 Tips & Tricks -- contributions welcome!
-
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!
Predictable destructors is one of the places where C++ shines. So, in properly coded C++, a single exit point is one more of a "style", or personal preference, since the method cleanup will always be done. On other languages, multiple exit points can lead corrupt data or leaks, and can introduce bugs. So, as a general rule, I try to avoid *LOTS* of exit points. A couple of exit points is acceptable in my rules. But this is not a strong rule: formally, languages that have exceptions ALWAYS have multiple exit points, because an exception potentially can occur at any point.
-
Marc Clifton wrote:
void Foo()
Marc Clifton wrote:
return ret;
*ahem* Nish :-D
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!
-
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 use a return variable that gets assigned a default value. This way I can make sure that I'm always returning a valid value. I do break loops when the time calls for it, mainly because I don't want my code to be inefficient. Although I tend to use to use the
breakstatement sparingly, more so I will usecontinue. If I need to break the iteration completely I'll do so in the conditions if possible (unless I’m modifying someone else’s code – I don't make many changes as possible in that regard because you never know what impact it could have on the system). The main reason I do this is because for a long method it makes it easier to follow the flow of execution IMO. Jeremy Falcon -
Drew Stainton wrote:
never use break in loops
What, never? Doesn't that make any linear search you do (for example finding a particular element in an array) a bit inefficient? Once you've found what you're looking for, surely you don't process the rest of the elements anyway?
Graham Bradshaw wrote:
surely you don't process the rest of the elements anyway?
Of course not! That's what I meant by 'I include the variable in the conditional for the loop' For a linear search, the variable would be set to 'found' and the loop would terminate in the conditional on the next iteration. Cheers, Drew.
-
Marc Clifton wrote:
void Foo()
Marc Clifton wrote:
return ret;
*ahem* Nish :-D
:laugh: I passed right over that one. Jeremy Falcon
-
Drew Stainton wrote:
I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise.
Ah, very nifty! 20 years of programming, and I never thought of that. In fact, I don't think I've even ever seen it in other people's code. :doh: Marc VS2005 Tips & Tricks -- contributions welcome!
I rarely ever see this done as well. It's not as efficient as using 'break' because the loop has to hit the conditional for the next iteration before it can end. I find it much easier to read and debug. I was big on state and flow diagrams many years ago and this made it much easier to relate the diagrams to the implementation. Cheers, Drew.
-
Drew Stainton wrote:
I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise.
Ah, very nifty! 20 years of programming, and I never thought of that. In fact, I don't think I've even ever seen it in other people's code. :doh: Marc VS2005 Tips & Tricks -- contributions welcome!
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 :-> -
I always have one exit point at the end of the method and never use break in loops. It's akin to goto in my mind - another tool of the devil. I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise. Cheers, Drew.
Drew Stainton wrote:
I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise.
I use this approach as well, except when you using
foreachbecause, of course, there's no place to test the conditional as there is in afororwhileloop. Of course, one could use an enumerator in awhileloop instead:bool found = false;
IEnumerator en = someCollection.GetEnumerator();while(!found && en.MoveNext())
{
if(en.Current == soughtAfterValue)
{
// Take some action.
found = true;
}
}return found;
However, I usually take this approach:
bool found = false;
foreach(SomeObject obj in someCollection)
{
if(obj == soughtAfterValue)
{
// Take some action.
found = true;
break;
}
}return found;
I think either way is fine, but I think the second approach is a little clearer. So I don't think breaks within loops are automatically bad. I do like to avoid more than one return within a method, however. I break this rule from time to time if I think it will make the algorithm clearer, but I like having one return at the bottom of the method.
-
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!
Nope. I'll exit when I damn well please. ;) Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
-
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 do try and aim on having a single exit point for methods, but with C++ it isn't quite as important IMHO (thanks to destructors and smart pointers, etc.) - and it can lead to some very deep nesting, which might not necessarily be that readable. Most people I've spoken to in the office agree that it is preferable to have a single exit point, especially when maintaining other peoples code. As for loops - I use break often. Shrug.
The Rob Blog
Google Talk: robert.caldecott -
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!
It depends. Sometimes having just one exit point makes it easier to read. Sometimes it doesn't. I just try and write code that is easy to read and maintain. So, I don't have a hard and fast rule.
My: Blog | Photos "Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious
-
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 try to keep local variables to a minimum so that multiple exit points don't cause a problem. I find they make code cleaner and easier to read as long as you don't have to change a lot of state in order to exit. Having to do that just tells me that the method is trying to do too much and needs to be simplified. I rarely have methods with blocks nested more then 1 or 2 deep, and never have nested try catch blocks.
-
Drew Stainton wrote:
I start by assigning a default return value to a local variable and then use that variable as part of the conditional in whatever loops I'm using - nested or otherwise.
I use this approach as well, except when you using
foreachbecause, of course, there's no place to test the conditional as there is in afororwhileloop. Of course, one could use an enumerator in awhileloop instead:bool found = false;
IEnumerator en = someCollection.GetEnumerator();while(!found && en.MoveNext())
{
if(en.Current == soughtAfterValue)
{
// Take some action.
found = true;
}
}return found;
However, I usually take this approach:
bool found = false;
foreach(SomeObject obj in someCollection)
{
if(obj == soughtAfterValue)
{
// Take some action.
found = true;
break;
}
}return found;
I think either way is fine, but I think the second approach is a little clearer. So I don't think breaks within loops are automatically bad. I do like to avoid more than one return within a method, however. I break this rule from time to time if I think it will make the algorithm clearer, but I like having one return at the bottom of the method.
Leslie Sanford wrote:
So I don't think breaks within loops are automatically bad
I totally agree - didn't mean to imply they were bad. I don't like using them but that's just my choice. You're right about foreach. To be honest I don't use it if the loop has early termination conditions. In those cases I use an enumerator. I really like knowing up front all of the conditions the loop is dependent on. Cheers, Drew.