The Weird and The Wonderful

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

qualitychecker wrote:

(1) : prevent against '=' instead of '==' : always put constants first

Member 4487083 wrote:

the compiler will complain

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;
------------------------------------

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

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;
}  

GibbleCH wrote:

And what the heck kind of code would they put in the else if you don't technically need an else?

if (dt == NULL)
	return false;
if (dt.Rows.Count == 0)
	return false;
 
return (t.Rows[0]["Number"].ToString() == "1");

vnike wrote:

They break the clients when modified.

PIEBALDconsult wrote:

And how about removing the .ToString and .Equals ?

Chris Meech wrote:

The slower they work, the better.