Programming peeve of the Day
-
Is snot.
if ( !condition )
{
// Do something else
}return ;
I believe to be totally proper it should be;
if ( !condition )
{
// Do something else
return;
}return ;
The less you need, the more you have. JaxCoder.com
-
No religion in the lounge! ;p
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I believe to be totally proper it should be;
if ( !condition )
{
// Do something else
return;
}return ;
The less you need, the more you have. JaxCoder.com
-
What's wrong with returning from inside an
if? The rule about only returning at the end of a function leads to convoluted code where a flag is repeatedly used to bypass stuff just to reach the end of the function. Pure dross.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
If I had a lawn... :mad:
We have a saying here in the south; Hold my beer[^].
The less you need, the more you have. JaxCoder.com
-
I would never do it the same, but I can understand it as a hint and that is ok. Of course
if (condition) return;
// Do otherwhisewould be more appropriate On the other hand: Is it really worth to discuss such little things?
You're asking if it's worth having a pointless whinge about something others do that's outside of one's control? What a silly question!
cheers Chris Maunder
-
I like single exit points... That code would drive me nuts too...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Bonus points to JSOP! I actually like having two exit points at most 1st at the very top if your initial sanity checks on input parameters fail. Get that out of the qay early 2nd at the very end of the routine.
cheers Chris Maunder
-
Bonus points to JSOP! I actually like having two exit points at most 1st at the very top if your initial sanity checks on input parameters fail. Get that out of the qay early 2nd at the very end of the routine.
cheers Chris Maunder
That's what I like too. If the function is something easy... just one return at the end. If the function is something normal size... what you said. If the function is big... I do a second function to "check all needed stuff" at the beginning and then what you said.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
What's wrong with returning from inside an
if? The rule about only returning at the end of a function leads to convoluted code where a flag is repeatedly used to bypass stuff just to reach the end of the function. Pure dross.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.If the return is within an "check initialized stuff" at the beginning... nothing. If there are 3 or more returns... it might get so confusing / convoluted as having only one at the end.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
What's wrong with returning from inside an
if? The rule about only returning at the end of a function leads to convoluted code where a flag is repeatedly used to bypass stuff just to reach the end of the function. Pure dross.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.If you have allocated anything that is not an automatic object that can be risky. I have dealt with a few customers who had explicit code-style prohibitions against multiple return statements. Given the rest of the nonsense we had to deal with from them that was pretty much ignored. I hated those SFBs so much I refuse to buy any of their products ever again. To give a clue, they used to be referred to as a purveyor of expensive ink.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Bonus points to JSOP! I actually like having two exit points at most 1st at the very top if your initial sanity checks on input parameters fail. Get that out of the qay early 2nd at the very end of the routine.
cheers Chris Maunder
I take a similar approach but I don't limit myself to just one return there. I let each sanity check have its own return statement because I find easier to deal with when debugging. Following the input sanitization I try to not have any returns unless a value is returned and then only at the bottom.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Greg Utas wrote:
The rule about only returning at the end of a function leads to convoluted code
As opposed to it not being clear when and where something can be returned.
It's quite clear, right in the
returnstatement. If the onlyreturnis at the end of the function, you have to find all the places that can set the returned value, and figure out whether that value survives to the end of the function or gets updated.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
If the return is within an "check initialized stuff" at the beginning... nothing. If there are 3 or more returns... it might get so confusing / convoluted as having only one at the end.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Sure, but that's just convoluted code. Prolonging the confusion by also having to reach the end of the function is only going to make things worse.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
If you have allocated anything that is not an automatic object that can be risky. I have dealt with a few customers who had explicit code-style prohibitions against multiple return statements. Given the rest of the nonsense we had to deal with from them that was pretty much ignored. I hated those SFBs so much I refuse to buy any of their products ever again. To give a clue, they used to be referred to as a purveyor of expensive ink.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Good point about automatic objects. Fortunately, C++ now has
unique_ptr, but some languages might not have an equivalent.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I take a similar approach but I don't limit myself to just one return there. I let each sanity check have its own return statement because I find easier to deal with when debugging. Following the input sanitization I try to not have any returns unless a value is returned and then only at the bottom.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Rick York wrote:
I let each sanity check have its own return statement
Full disclosure: I do the same if it makes it cumbersome / ugly otherwise. But one test/return section at the top.
cheers Chris Maunder
-
Chris Maunder wrote:
Your rewrite is how it should be done.
Why? It's not as clear as to what the code will do. Plus, returning from inside an if is bad form.
Sure, in a function that is 1000 lines long, it isn't clear. In one that fits on the screen is quite obvious. But I'd argue that a function that long isn't clear either way. :-D
-
if (condition)
{
return;
}
else
{
// Do something else
}cheers Chris Maunder
It all depends on which measuring stick is used... - # exits in a function - # lines of code - # lines of comments - # paths in the code - readability, - maintainability, modifiability - only use positive condition tests (! using ! and certainly ! !!) And of course if you (think you) are paid by lines of code produced there are many other "solutions"
-
if (condition)
{
return;
}
else
{
// Do something else
}cheers Chris Maunder
Visual Studio would show you that the else branch in unnecessary.
-
if (condition)
{
return;
}
else
{
// Do something else
}cheers Chris Maunder
Hmm, to trying to please people who want a single exit point and clear intent when processing is completed:
if (condition)
{
goto returnStatement;
}
// Do something else:returnStatement
return;
X| :laugh: X|
-
if (condition)
{
return;
}
else
{
// Do something else
}cheers Chris Maunder
My career best:
function doNothing(something) {
return something;
}Nothing succeeds like a budgie without teeth.
