|
Oddly enough, I just got rid of some code that looked a bit like that...
bool InitRoutine()
{
bool failed=false;
ValType val;
HRESULT ans = GetValue1(val);
if (ans==S_OK)
{
globalVal1 = val;
}
else
{
failed = failed || true;
}
ans = GetValue2(val);
if (ans==S_OK)
{
globalVal2 = val;
}
else
{
failed = failed || true;
}
ans = GetValue3(val);
if (ans==S_OK)
{
globalVal3 = val;
}
else
{
failed = failed || true;
}
ans = GetValue4(val);
if (ans==S_OK)
{
globalVal4 = val;
}
else
{
failed = failed || true;
}
return !failed;
}
|
|
|
|
|
Ah a follower of the 'there must be only one return statement per method cult'.
I'll be more enthusiastic about encouraging thinking outside the box when there's evidence of any thinking going on inside it. - pTerryBizSquawk
|
|
|
|
|
A misguided one, gives the rest of us a bad name.
Though I don't see where any other return s would go.
|
|
|
|
|
Err ! Was that guy thinking to leave the company while writing this code ?
|
|
|
|
|
Beautiful...
failed = failed || true;
|
|
|
|
|
Short circuit evaluation, man! You don't want to be setting failed to true if it is already!
|
|
|
|
|
What's so bad about that? I'd do it like the following but I've seen far worse than that code:
if (dt == NULL)
return false;
if (dt.Rows.Count == 0)
return false;
return (t.Rows[0]["Number"].ToString() == "1");
|
|
|
|
|
How would you think of this?
return dt != null && dt.Rows.Count > 0 && (int)t.Rows[0]["Number"] == 1;
The last part depends on the data the table contains. But if its clear that the column is filled with integers then this should be more efficient.
|
|
|
|
|
Nah.
This is much more difficult to debug, how would you set a breakpoint anywhere inside such a complex expression?
|
|
|
|
|
Why would you need to? I never have. And for that purpose you can write it specifically for debugging and then put it back to "normal" once you're satisfied with that bit (and not with conditional compiling).
I had to do that sort of thing once a week or so ago. It works for me, others may choose other paths.
|
|
|
|
|
I'm afraid you overlooked the little joke icon; I seldom set a breakpoint so I will not
break up things that belong together just to facilitate a potential later debug action.
|
|
|
|
|
Oh, yes, indeed I did, thanks. It's because the coffee was still dripping. We had a power outage this morning so the coffee maker didn't start automatically. I'd better get a UPS for it.
|
|
|
|
|
If the statement fails, just put a breakpoint on the entire statement. Then, highlight each portion, right click, and select 'Add to Watch'. Viola! You'll see whether or not the statement passed. Rinse and repeat.
|
|
|
|
|
And yes...I know it was a joke. But still...not sure if everyone knows of such
|
|
|
|
|
I certainly didn't, and I probably won't the next time I could use it.
|
|
|
|
|
Thank you for the tip; I rarely use those fancy debug features.
It does widen the scope of the breakpoint, hence requires more human intervention to narrow it down,
but it works.
|
|
|
|
|
|
Right, that's how I do it. Though it may be more a matter of readability/maintainability than of efficiency (in my opinion).
|
|
|
|
|
Just a question:
What if there is no value integer or otherwise in t.Rows[0]["Number"]?
Wouldn't this result into a crash.
Learn from the mistakes of others, you may not live long enough to make them all yourself.
|
|
|
|
|
Thats why I wrote the following after the code block:
The last part depends on the data the table contains. But if its clear that the column is filled with integers then this should be more efficient.
Probably I should have added: ... and otherwise the code will explode.
|
|
|
|
|
I believe it will be another if...else IF the developer knew to deal with the DBNull issue that you mentioned. Now, how many ELSE he has?
|
|
|
|
|
Nice (and compact) solution !!
Still depends on the precedence priorities of the language / the optimization of the underlaying compiler ..
More safe and maintainable code:
------------------------------------
bool res = false;
if (null == dt)
else if (null == dt.Rows)
else if (dt.Rows.Count < 0)
else res = (1 == (int)dt.Rows[0]["Number"]);
return res;
------------------------------------
Rules to be applied :
(1) : prevent against '=' instead of '==' : always put constants first
(2) : always control potential nulls even if seems useless versus construction rules (ex null == dt.Rows)
(3) : provide debugging / tracing points in case of future problems
(4) : write readable code
(5) : single return output point
Shears and happy new year.
modified on Saturday, January 10, 2009 5:03 AM
|
|
|
|
|
qualitychecker wrote: Still depends on the precedence priorities of the language
Uh, yeah, so? Are we going to get into that again?
qualitychecker wrote: always put constants first
If you can remember to do that, you're smart enough not to make that mistake in the first place.
qualitychecker wrote: provide debugging / tracing points in case of future problems
No thanks.
|
|
|
|
|
PIEBALDconsult wrote: If you can remember to do that, you're smart enough not to make that mistake in the first place.
I agree, although one might argue that on the rare occasion one might forget to apply this strange habit,
the statement could still be correct (i.e. one could accidentally forget to drop one of the = signs).
|
|
|
|
|
qualitychecker wrote: Rules to be applied :
(1) : prevent against '=' instead of '==' : always put constants first
(2) : always control potential nulls even if seems useless versus construction rules (ex null == dt.Rows)
(3) : provide debugging / tracing points in case of future problems
(4) : write readable code
(5) : single return output point
You cannot satisfy rule (4) AND all the others
--
"My software never has bugs. It just develops random features."
|
|
|
|