|
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."
|
|
|
|
|
qualitychecker wrote: (1) : prevent against '=' instead of '==' : always put constants first
I used to do this a bit when I was writting C, but I don't think there is any benefit with C#. Try doing a single = in a in a if statement and the compiler will complain. So can anybody see a benefit of doing (null == x)?
Actually, I've just checked, it doesn't always complain, although I think it does sometimes complain.
modified on Monday, January 12, 2009 9:22 AM
|
|
|
|
|
Member 4487083 wrote: the compiler will complain
Except when using booleans.
|
|
|
|
|
qualitychecker wrote: 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;
------------------------------------
Oops - hate to say this, but if dt.Rows.Count == 0 - i.e. the table is empty - then that code will throw an array-out-of-bounds exception. You meant else if (dt.Rows.Count <= 0) , right?
-- T
|
|
|
|
|
would the same work for a switch statement?
switch (null)
{
case dt:
{} break;
case dt.rows:
{} break;
default:
{}
}
or how about this?
switch (true)
{
case (dt == null):
{} break;
case (dt.rows == null):
{} break;
case (dt.rows[0]["number"] == 0):
{} break;
default:
{} break;
}
maybe nest either one in a do loop till the computer gets its sh*t straight.
please tell me why this is wrong, as i am just learning.
|
|
|
|
|
Thats fine code: logical development (right order) and easy to understand and maintain.
Greetings from Germany
|
|
|
|
|
This code reminds me one developer working under me, according to her every if has to have else, you can't use if alone.
|
|
|
|
|
Those are the people you don't have working for you for long...one would hope.
|
|
|
|
|
Yeah Its been two years. I asked the HR department to improve filtering & recruitment process but as they are looking for cheap labor I don't think this will ever happen.
|
|
|
|
|
That's not cheap though, it's way more expensive in the long run if they aren't competent. More fixing bugs, and longer development time.
And what the heck kind of code would they put in the else if you don't technically need an else?
|
|
|
|