C#and .NET coding practices 
Author Message
 C#and .NET coding practices

I found all sorts of useful info and links up on your blog - thanks again -
and I quite agree about the need for deterministic finalization.

Forgive me for changing topics. I've been asked to put together some
guidelines for "best" coding practices for C# and .NET apps. I wanted to get
a lot of input on the subject so I figured this is as good a time and place
to start as any.

As a starting example, I've seen code like this...

Foo c = someObj as Foo;
c.SomeMethod();

I don't like the above because unless you code for the case where c == null
then I'd prefer to see it written as...
Foo c = (Foo)someObj;
because if the cast fails you will get a typecast exception instead of a
null reference exception (which is misleading).

Any and all thoughts on the subject are welcome. Thanks

Dave


Quote:
> Thanks Dave. Yes, that's why I have tempered my comments to its usable
> but hard over flawed (especially after sorting out my thoughts with
> Don). Any architecture that can have these kind of circular cycles (like
> COM) can itself lead to such problems of cycle breaking and that just
> gets reflected in COM Interop with .NET.



Fri, 24 Jun 2005 06:52:08 GMT  
 C#and .NET coding practices


Quote:
> I found all sorts of useful info and links up on your blog - thanks
again -
> and I quite agree about the need for deterministic finalization.

> Forgive me for changing topics. I've been asked to put together some
> guidelines for "best" coding practices for C# and .NET apps. I wanted to
get
> a lot of input on the subject so I figured this is as good a time and
place
> to start as any.

> As a starting example, I've seen code like this...

> Foo c = someObj as Foo;
> c.SomeMethod();

> I don't like the above because unless you code for the case where c ==
null
> then I'd prefer to see it written as...
> Foo c = (Foo)someObj;
> because if the cast fails you will get a typecast exception instead of a
> null reference exception (which is misleading).

> Any and all thoughts on the subject are welcome. Thanks

I find the latter a lot more readable, because the cast is right between the
variable and the assignment operator, so it's like looking at some sort of
"filter" between these two; which, if fact, it is.

Massimo



Fri, 24 Jun 2005 07:28:53 GMT  
 C#and .NET coding practices


Quote:
> > As a starting example, I've seen code like this...

> > Foo c = someObj as Foo;
> > c.SomeMethod();

> > I don't like the above because unless you code for the case where
> > c == null then I'd prefer to see it written as...
> > Foo c = (Foo)someObj;
> > because if the cast fails you will get a typecast exception instead
> > of a null reference exception (which is misleading).

> > Any and all thoughts on the subject are welcome. Thanks

> I find the latter a lot more readable, because the cast is right between
the
> variable and the assignment operator, so it's like looking at some sort of
> "filter" between these two; which, if fact, it is.

Add-on: the first form will actually be more readable in situations like
this:

(someObj as SomeDerivedClass).SomeMethod();

This would be better than

((SomeDerivedClass) someObj).SomeMethod();

Massimo

P.S.
All of this is IMHO, obviously :-)



Fri, 24 Jun 2005 07:37:58 GMT  
 C#and .NET coding practices
Are you stating that you  would prefer to see it written as ???
(someObj as SomeDerivedClass).SomeMethod();

If so, I prefer to see it as
((SomeDerivedClass)someObj).SomeMethod();
because if an exception is thrown you will get a more accurate exception
message and the intent is much clearer. I do not like to use the "as"
keyword unless the result is tested for null.


Quote:


> > > As a starting example, I've seen code like this...

> > > Foo c = someObj as Foo;
> > > c.SomeMethod();

> > > I don't like the above because unless you code for the case where
> > > c == null then I'd prefer to see it written as...
> > > Foo c = (Foo)someObj;
> > > because if the cast fails you will get a typecast exception instead
> > > of a null reference exception (which is misleading).

> > > Any and all thoughts on the subject are welcome. Thanks

> > I find the latter a lot more readable, because the cast is right between
> the
> > variable and the assignment operator, so it's like looking at some sort
of
> > "filter" between these two; which, if fact, it is.

> Add-on: the first form will actually be more readable in situations like
> this:

> (someObj as SomeDerivedClass).SomeMethod();

> This would be better than

> ((SomeDerivedClass) someObj).SomeMethod();

> Massimo

> P.S.
> All of this is IMHO, obviously :-)



Fri, 24 Jun 2005 08:19:25 GMT  
 C#and .NET coding practices


Quote:
> Are you stating that you  would prefer to see it written as ???
> (someObj as SomeDerivedClass).SomeMethod();

Well, yes, I find it more descriptive of what's actually happening.

As I said before, in the case of

SomeClass s = (SomeClass) someOtherObject;

it looks like you're placing a "filter" (the cast) between the original
object and the assignment operator.
If you instead write

SomeClass s = someOtherObject as SomeClass;

now the conversion is not in it "rightful" place, and this is less immediate
to read.

Also, if you have multiple casts, I think you'll agree that

SomeClass s = (SomeClass) (SomeOtherClass) yetAnotherObject;

is a lot better than

SomeClass s = yetAnotherObject as SomeOtherClass as SomeClass;

Yes, these kind of casts is totally useless, but we're discussing form here
;-)))

Anyway, when it comes to method calls, I think things change a lot.
In the basic case you have the two possibilities

((SomeClass) someObject).SomeMethod();
(someObject as SomeClass).SomeMethod();

Now, the situation is opposite to what we discussed before: reading the
statements, the method call is on the right of the object, so the second one
places the cast in the most natural place to see it at first sight.
This time, also, multiple casts can really happen, and the latter syntax is
*really* better in this case:

((SomeOtherClass) ((SomeClass) someObject).SomeMethod()).SomeOtherMethod();

is way less readable than

((someObject as SomeClass).SomeMethod() as
SomeOtherClass).SomeOtherMethod();

This way the natural reading order is preserved, and you don't have to look
back and forth to understand what's happening.

It's the same thing as postfix or infix notation in arithmetics: I hope
you'll agree that "2 * 2 + 2" is someway more readable than "2 2 * 2 +" :-)

Quote:
> If so, I prefer to see it as
> ((SomeDerivedClass)someObj).SomeMethod();
> because if an exception is thrown you will get a more
> accurate exception message

I don't follow you here... can you explain ?

Quote:
> and the intent is much clearer.

No, I don't agree on this.

Quote:
> I do not like to use the "as" keyword unless the result
> is tested for null.

Well, if you call methods (or do anything else) on a possibily null
reference you're going to need to test it anyway... and if you don't test
it, neither syntax will save you from a NullPointerException.

Massimo



Fri, 24 Jun 2005 08:58:14 GMT  
 C#and .NET coding practices
inline...

Quote:
> > Are you stating that you  would prefer to see it written as ???
> > (someObj as SomeDerivedClass).SomeMethod();

<snip>

Quote:

> > If so, I prefer to see it as
> > ((SomeDerivedClass)someObj).SomeMethod();
> > because if an exception is thrown you will get a more
> > accurate exception message

> I don't follow you here... can you explain ?

I think we have a difference of opinion about the use of the keyword "as".
Your statements make sense if there is no difference between using "as" and
a typecast - you are looking at the readability of the source code and I am
looking at the expected outcome if the cast fails. If a typecast fails I
will get that exception. However, when using "as" if the types do not agree
the result is to put a null value on the stack. When the next operation
comes along that uses the result the operation will throw a null reference
exception. When this gets propagated up the call stack and eventually
reported to the user I would rather have it tell me that a typecast failed
as this is more descriptive of the problem and makes it easier for me to
track down the ultimate cause of the failure.

Quote:
> > I do not like to use the "as" keyword unless the result
> > is tested for null.

> Well, if you call methods (or do anything else) on a possibily null
> reference you're going to need to test it anyway... and if you don't test
> it, neither syntax will save you from a NullPointerException.

Exactly....I prefer to use "as" when I expect it to fail (e.g. I might have
multiple types stored in an array and execute different branches based on
the type) and use a typecast if I never expect it to be a different type.


Fri, 24 Jun 2005 09:38:08 GMT  
 C#and .NET coding practices


Quote:
> I think we have a difference of opinion about the use of the keyword "as".
> Your statements make sense if there is no difference between using "as"
and
> a typecast - you are looking at the readability of the source code and I
am
> looking at the expected outcome if the cast fails. If a typecast fails I
> will get that exception. However, when using "as" if the types do not
agree
> the result is to put a null value on the stack.

Oh, sorry, I didn't know this.
Then you're right, if you're not sure about the type you really have a cast
is definitely better.

BTW, what an awful way to handle a type conversion operator... :-(

Massimo



Fri, 24 Jun 2005 10:05:09 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Newbie: separate big .cs file into small .cs files

2. VS.NET: Adding one .cs file to more then one project

3. Newbie porting EventSample.cs to ASP.NET

4. Adding cs-files from another directory in VS.NET

5. OT: HUMOR Klingon Coding Practices

6. code review practices

7. Code review practices

8. Safe coding practices (was Re: Bug in users command)

9. Wanted: List of legal but poor coding practices.

10. Is This Bad Coding Practice?

11. C Coding Practice

12. Is this acceptable coding practice ?

 

 
Powered by phpBB® Forum Software