|
Mike, you're not even close to how screwed up someone could make this! 
I worked with a guy who was intent on cover EVERY possibility. His program executed 700 lines of code when tabbing between fields. If anyone actually clicked something, it go ugly ....
|
|
|
|
|
I've no doubt that it could be more screwed up and I've seen it when I was getting payed to program.
I wonder how some people get into the field and even more how they stay.
|
|
|
|
|
Yeah, the lack of ability in some cases is amazing, and not in a good way.
My boss tells a story of a former employee who made cut-n-paste an art form. Modern art form. This person appears to have never written a line of code -- everything was copied from other programs and web sites, and this person could not understand why the program would not work.
In another situation I taught a COBOL programmer with 5 years experience how to program. I am not a COBOL programmer and have never compiled a single line. This is not picking on COBOL -- this guy did not understand program flow. OTOH, he was fantastic at phone support, which is where he should have been.
|
|
|
|
|
My first developer job at Microsoft required me to analyze code written by a 'developer who got promoted so is no longer available. I and another dev spent hours analyzing this C language mess. Finally, after hours of analysis, we traced deep enough to get to the root of what the code was doing. Result? It returned the number 1.
Yup, that is all the entire 20K lines of code did. The reason it never worked? The array this was used to dereference only had 1 element.
Sheesh.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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 return statement. If the only return is 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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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. 
|
|
|
|
|
Agreed! That’s what GOTO is for.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
|
Obviously it should have been:
if (!condition)
{
}
else
{
return;
}
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Whehe, that's evil
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Got it before I did! 
|
|
|
|
|
I would never do it the same, but I can understand it as a hint and that is ok.
Of course
if (condition) return;
would be more appropriate
On the other hand: Is it really worth to discuss such little things?
modified 5-Apr-21 21:01pm.
|
|
|
|
|
Member 15092515 wrote: On the other hand: Is it really worth to discuss such little things?
You're absolutely correct. Let's discuss this, instead:
if (condition)
{
return;
}
else
{
// Do something else
}
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Ah ok I see you have a problem with 'if ... else' 
[Edit]
Is see in your profile "In real life, a research chemist."
Yep, better stop programming. This because programming follow strict rules while chemistry has only exceptions
modified 5-Apr-21 21:01pm.
|
|
|
|
|
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
|
|
|
|
|
when you refactor some code and are too afraid to remove else clauses.
I'd rather be phishing!
|
|
|
|
|
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, 2013
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
