|
Dammit, how did I miss that one? 
TTFN - Kent
|
|
|
|
|
What else is ambiguous about "else" ?
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
The whole thought of processing the exception first upon returning from a call is so counter intuitive to the way we think; we process good/expected results first, THEN proceed to look at the outliers.
When I read the code, I think the developer is expecting an error so prepares to handle it first.
It all goes back to the maxim: write clean code; there is nothing wrong with indentation or else statements. Also, write comments on what the process is doing and why, don't assume the code is so well written its intuitively obvious what the desired result is.
|
|
|
|
|
Tim Carmichael wrote: process is doing and why
Agree with the why. I can read the code to see what it's doing. I've seen so many comments // declare variables then // call the function then // process result
So helpful.
Tim Carmichael wrote: there is nothing wrong with indentation or else statements
egregious indentation and if/else's are problems when there are too many levels, usually more than two. This leads to functions that are too long and have multiple purposes. Better to refactor the code and move the different cases into different functions.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Better to refactor the code and move the different cases into different functions.
I absolutely agree with this...
The worst If/Then block I ever had to write was in Fortran for some equipment routing in an automated factory. The 'If' statement was 23 lines - and that is just the 'If' portion, not the code executed if the statement was true.
I had a block of comments preceding it explaining what it was doing and why with a warning that 'if you break it, you get to maintain it'.
But, if was an if/then/else block to determine an action; it wasn't multiple nested blocks within each other.
|
|
|
|
|
ugh. I feel the pain just reading that.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I once encountered a method that was over 1000 lines long. :/
".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
|
|
|
|
|
Tim Carmichael wrote: counter intuitive to the way we think; we process good/expected results first, THEN proceed to look at the outliers.
It's a mixed bag for me. I prefer to exit a method as early as possible, when it makes sense (performing sanity checks on method parameters to ensure they're not null at the top of the method, and throw argument exceptions if they don't meet expected values). After that, I let code go where it needs to go, letting the "true" conditions happen first, and let else handle the "false" conditions.. In the end, I also strive to have a single point of exit instead of having multiple returns sprinkled throughout a method.
".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
|
|
|
|
|
John Simmons / outlaw programmer wrote: strive to have a single point of exit
That can sometimes produce code that looks like an extortionist got hold of it. Here's were some judicious use of goto may be warranted.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Here's were some judicious use of goto may be warranted.
Just say no to goto.
I typically define a result variable, and progress through the method setting that variable as appropriate. If I have a longish chain of if/else clauses I indent them like so:
int result = 0;
if (condition)
{
}
else if (condition)
{
}
... and so on
return result;
If conditions are favorable, I'll use a switch statement instead of if/else, but I still try to have only one exit point (exceptions notwithstanding).
I also strive to keep my methods short and specific to the process/task described by the name of the method.
".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
|
|
|
|
|
John Simmons / outlaw programmer wrote: keep my methods short and specific
That's the key.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
John Simmons / outlaw programmer wrote: I also strive to have a single point of exit instead of having multiple returns sprinkled throughout a method.
Boring...You're taking all the fun out of debugging!!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Yeah, I know. But debugging is exciting enough without adding multiple-exit-points sauce. 
".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
|
|
|
|
|
Tim Carmichael wrote: It all goes back to the maxim: write clean code; there is nothing wrong with indentation or else statements. Also, write comments on what the process is doing and why, don't assume the code is so well written its intuitively obvious what the desired result is. |
My code is always intuitively obvious, since I intuited it, until the next day, that is!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
if (Agree())
{
return true;
}
else
{
return false;
}or
return Agree();
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I tend to favor single returns for debugging reasons, if it doesn't result in absurd code. However, quite often it results in code that is more clear.
|
|
|
|
|
Resharper uses this as one of its built-in rules and will suggest re-writing your code to exit early as the article describes.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Tim Oxley wrote: Error handling is noise.
Got it, if a problem occurs then the whole app should die.
I wonder if he was part of the team that wrote the usb interface for the windows phone, failure to read and the whole phone reboots.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
The Federal Trade Commission has confirmed that it is investigating Facebook’s privacy practices after it was revealed that the company allowed Cambridge Analytica access to the personal data of some 50 million Facebook users without their expressed consent. This week in shocking news
|
|
|
|
|
Kent Sharkey wrote: This week in shocking news
And which one is the shocking news?
That Facebook missuses data? Or that the FTC is actually investigating it? 
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.
|
|
|
|
|
yes
TTFN - Kent
|
|
|
|
|
 
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.
|
|
|
|
|
Lets see, you put your data on an international billboard and are surprised that someone saw it??
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
People do seem shocked. I can’t think why. 
TTFN - Kent
|
|
|
|
|
In which we describe how we decided not to cover the newest cellphone-cancer study. Go ahead and take that call
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
