Magic of if...else...programming

[Robert Rohde]

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. :-D

[che3358]

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? :)

[qualitychecker]

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

[PIEBALDconsult]

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.

[Luc Pattyn]

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). :-D

Luc Pattyn [Forum Guidelines] [My Articles]

---

Love, happiness and fewer bugs for 2009!

---

[Tony Pottier]

There's nothing "horrible" in this code. Industry is all about making something that works and that's easily understandable by your co-workers. Sure, this is going over the top, and I'd do something that was suggested above, like:

if (dt == NULL)
return false;
if (dt.Rows.Count == 0)
return false;

return (t.Rows[0]["Number"].ToString() == "1");

But, seriously, who cares? It's readable and it will run as fast as return dt != null && dt.Rows.Count > 0 && (int)t.Rows[0]["Number"] == 1;

[Stephen Hewitt]

Agreed.

Steve

[Deflinek]

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."

[User 4483848]

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

[PIEBALDconsult]

Member 4487083 wrote:

the compiler will complain

Except when using booleans.

[kenrentz]

With thinking like that you'll never make it in HR :-D

[Jeremy Tierman]

Beautiful... failed = failed || true;

[Timothy Byrd]

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

[GibbleCH]

There goes my 7 year plan

[vnike]

Other than what has been already pointed out..."code trimming" for lesser cycles, I also suggest not to use the string literals as such. They break the clients when modified. static readonly string colName = "Number"; static readonly string colVal = "1"; -------------------------- if(dt != null && dt.Rows.Count > 0) { return dt.Rows[0][colName].ToString().Equals(colVal); } else return false;

[S Senthil Kumar]

vnike wrote:

They break the clients when modified.

Only if the client is a different assembly. I would imagine that column names and indexes would be private to a class, so I don't see any issue with using const there.

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

[Adrian Cole]

Short circuit evaluation, man! You don't want to be setting failed to true if it is already! :)

[Aerman4567]

would the same work for a switch statement?

switch (null)
{
case dt:
{} break;
case dt.rows:
{} break;
default:
{/*actual exec., we have asserted everything's cool*/}
}

or how about this?

switch (true)
{
case (dt == null):
{/*handle the case that dt is null,
i.e. assign it something*/} break;
case (dt.rows == null):
{/*handle the case that dt.rows is null*/} break;
case (dt.rows[0]["number"] == 0):
{/*this element equals 0, it now needs to be assigned*/} break;
default:
{/*computer finally does something right*/} 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.