Special Case
-
For the sake of learning here, why do some of the examples use the abs function in their answers. Why not just i++?
-
And for sqrt(-1/64) do we get indigestion tablets?
-
Rewritten:
return (i == 0) ? 1 : i++;
In division, specifically in the denominator, this code eliminates the divide by zero issue. I think the OP (original programmer) had good intentions.
-
I just tried your method, and my compiler is generating a error about a method must return a value, so I fixed it. There is a version without bugs, hope it helps:
if (i < 0)
return 1 - abs(i);
else if (i == 0)
return 1;
else if (i > 0)
return 1 + abs(i);Sorry, I fail to see how you fixed it. Computers aren't very good at determining there is an unreachable path. Put an unconditional return 1 - abs(i) + abs(i); after all the if statements should fix it. (Especially if i is uint. Checking for negative numbers is really interesting in that case.)
-
For the sake of learning here, why do some of the examples use the abs function in their answers. Why not just i++?
MehGerbil wrote:
Why not just i++?
For one thing that would be the same as returning i. (Unless the i was passed with ref. Then you get two values for the price of one.)
MehGerbil wrote:
For the sake of learning here
That's rich. Trying to learn better coding by studying poor code harder.
-
MehGerbil wrote:
Why not just i++?
For one thing that would be the same as returning i. (Unless the i was passed with ref. Then you get two values for the price of one.)
MehGerbil wrote:
For the sake of learning here
That's rich. Trying to learn better coding by studying poor code harder.
-
For the sake of learning here, why do some of the examples use the abs function in their answers. Why not just i++?
-
It should be 'return i + 1'. ++i is a wasteful update of the variable i, assuming it's local (there's some serious issues if it isn't anyway), and i++ is just wrong because it returns i (before the statement) and not i + 1.
-
Just a quick one, but amused me when I saw it in code today.
if (i == 0)
return 1;
else
return i + 1;I'm not surprised, see it all the time. This happens as a result of changing the condition, i.e. the code was written for one condition, then the condition changed, and the code was updated without logical refactoring. Also, some developers like making code temporarily unreachable rather than commenting it out, i.e. putting the code into a block like:
if(false){...code...}
-
Just a quick one, but amused me when I saw it in code today.
if (i == 0)
return 1;
else
return i + 1;Developer took special math classes... :-D
-
That was interesting. Why is it that ++i is less efficient then returning i + 1? Isn't a calculation made (total of i + 1) made in memory somewhere regardless?
It's likely that compiler optimisations make it irrelevant in this case. But in the general case, she using ++i the value is copied into i after being calculated, then copied into the return variable. Using i+1 only copies it to the return variable (one less copy).
-
It's likely that compiler optimisations make it irrelevant in this case. But in the general case, she using ++i the value is copied into i after being calculated, then copied into the return variable. Using i+1 only copies it to the return variable (one less copy).