Best practices

[john doe]

A quick question, about so-called 'best practices', I'm interested in
which of A/B of the two examples people would choose, and why.

[A]
public enum MyEnum
{
Option1 = 0,
Option2 = 1,
Option3 = 2,
Option4 = 3
}


public enum MyEnum
{
Option1,
Option2,
Option3,
Option4
}

The second one:

[A]
public string Foo
{
get
{
return this.foo;
}
set
{
if ( this.foo != value )
return this.foo
}
}


public string Foo
{
get
{
return this.foo;
}
set
{
return this.foo
}
}

I'm also interested in best practices for null checks for paramters in
methods and other best practices. The Microsoft website has a few
(try/catch, chunky calls etc.) in its best practices page, but I'm
after a more comprehensive list.

Thanks

 

[john doe]

Glaring error/typo with the second example, which should read:

[A]
public string Foo
{
get
{
return this.foo;
}
set
{
if ( this.foo != value )
this.foo = value;
}



}



public string Foo
{
get
{
return this.foo;
}
set
{
this.foo = value;
}


}

 

[Steve Walker]

set
{
if ( this.foo != value )
this.foo = value;
}

What does this achieve, other than a needless string comparison? If they
are equal before the operation, after it foo == value, if they aren't,
foo == value. If you don't do the compare, same result.

 

[Andy Walldorff]

What does this achieve, other than a needless string comparison? If they
are equal before the operation, after it foo == value, if they aren't, foo
== value. If you don't do the compare, same result.

I guess it depends on which is the more expensive operation: a needless
comparison or a needless assignment (i.e. if the strings are equal). I'm
not sure, but I would typically just do the assignment. I would only
interogate the new value it it needed validation.

 

[Andy Walldorff]

A quick question, about so-called 'best practices', I'm interested in
which of A/B of the two examples people would choose, and why.

[A]
public enum MyEnum
{
Option1 = 0,
Option2 = 1,
Option3 = 2,
Option4 = 3
}


public enum MyEnum
{
Option1,
Option2,
Option3,
Option4
}

[snip]

It depends. If the actual values of the enumeration don't matter then I
would use B.

 

[Steve Walker]

A quick question, about so-called 'best practices', I'm interested in
which of A/B of the two examples people would choose, and why.

[A]
public enum MyEnum
{
Option1 = 0,
Option2 = 1,
Option3 = 2,
Option4 = 3
}


public enum MyEnum
{
Option1,
Option2,
Option3,
Option4
}

Depends on whether the integer values matter or not. If they are ever
persisted (to a file, a database, etc) then it's important that someone
doesn't come along later and do:

public enum MyEnum
{
Option0,
Option1,
Option2,
Option3,
Option4
}

It also matters if you want to do something like:

public enum MyEnum
{
Option0=1,
Option1=2,
Option2=4,
Option3=8,
Option4=16
}

DoSomething(MyEnum.Option1 | MyEnum.Option2);

 

[Steve Walker]

I guess it depends on which is the more expensive operation: a needless
comparison or a needless assignment (i.e. if the strings are equal).

Well, quite. I can't see a string comparison ever being cheaper than an
assignment.

I'm
not sure, but I would typically just do the assignment. I would only
interogate the new value it it needed validation.

Or if the 'assignment' wasn't just that, but required some pretty heavy
processing; revalidation of the whole object, parsing the string, etc.

 

[john doe]

Thanks for the replies, the two answers given - _not_ assigning
enumeration values unless its got the flags attribute, and _not_
comparing in the set, are practices I would use.

My other question was about null checking - and the best place to check
for null values in a chain of methods. For example, 3 methods:

method1(SomeCollection val)
method2(SomeCollection val)
method3(SomeCollection val)

with method1 calling method2 which calls method3. Assuming method3
iterates through the 'val' collection, is this where null checking
should be performed, or is it up to method2 or method3 to do the checks?

 

[Joe Fromm]

If method1 and method2 just pass through the val collection to method3
without otherwise accessing it, the null check should be left to method3.

I'd go farther and say that regardless of what method1 and method2 do, if
method3 can't handle the collection being null it should check for it. If
performance is critical at least assert that it is not null so you have a
chance of catching it in a debug build if the precondition is not met.

 

[Steve Walker]

Thanks for the replies, the two answers given - _not_ assigning
enumeration values unless its got the flags attribute, and _not_
comparing in the set, are practices I would use.

My other question was about null checking - and the best place to check
for null values in a chain of methods. For example, 3 methods:

method1(SomeCollection val)
method2(SomeCollection val)
method3(SomeCollection val)

with method1 calling method2 which calls method3. Assuming method3
iterates through the 'val' collection, is this where null checking
should be performed, or is it up to method2 or method3 to do the checks?

Depends entirely on the context, I'd say.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Well in the worst case it will be an comparision & an assignment , versus
only the assignment.

cheers,

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I would do it in method3 , it;s where it's used,
You may have the case where method3 is called from a place other than
method2 so if you do not check it inside method3 you could get an exception

cheers,

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

Well in the worst case it will be an comparision & an assignment , versus
only the assignment.

Indeed - but whereas the assignment will always be cheap, the
comparison *could* conceivably be very expensive - imagine two strings
which are both a million characters long, but only differ in the last
character.

 

[Helge Jensen]

with method1 calling method2 which calls method3. Assuming method3
iterates through the 'val' collection, is this where null checking
should be performed, or is it up to method2 or method3 to do the checks?

Why do null-check at all? if you don't check you will get an exception,
which has all the information about what went wrong.

What is your "null-check" going to do, that is better?

 

[Jon Skeet [C# MVP]]

Why do null-check at all? if you don't check you will get an exception,
which has all the information about what went wrong.

What is your "null-check" going to do, that is better?

1) Using an ArgumentNullException makes it clear that it was an
argument that was incorrect rather than logic inside a method

2) Using an ArgumentNullException can give more information about
*which* argument (or part of argument) was null

3) Throwing an exception before doing any other work leaves objects in
a more consistent state