.Net开发人员必须避免的5个常见的编程错误

来源：http://www.amazedsaint.com/2010/02/top-5-common-programming-mistakes-net.html

Some time back, I asked a question in Stackoverflow.com, about common programming mistakes .NET developers must avoid. The response was awesome, to say the least. I’m just listing down the top 5 developer crimes I picked, from the answers I received (regardless the votes).

1. Breaking the stack unnecessarily when you re-throw an exception

This a pretty ‘old thing’ - but surprisingly, still a very common mistake. As TheSoftwareJedi mentioned, you don’t really need to break the stack while throwing exceptions. I’ve done this myself when I was a beginner - and I’ve seen this more often than anything else when I do code reviews these days.

To clarify the point - What is the difference between

try { ..} catch (Exception ex) { throw ex; }

and 

try {..} catch(Exception ex) { throw; }  ?

And when you lose the stack trace, you can’t debug your app – and even worse, you can’t log your error details properly to your error log.

The MSDN guidelines on exception handling clearly states

Do not rethrow by throwing the same exception object.  This causes the stack trace for the original exception to be lost--use a lone "throw;" statement (without an object following it) to "rethrow" a catch exception.

2. Not using using to dispose objects

When ever you initialize an IDisposable object, it is a good practice to initiate it in a using statement to ensure the object is getting disposed properly, like this.

Most developers won’t do that. Greg Dean pointed the same.

Here is a little bit of re-cap from MSDN

As a rule, when you use an IDisposable object, you should declare and instantiate it in a using statement. The using statement calls the Dispose method on the object in the correct way, and it also causes the object itself to go out of scope as soon as Dispose is called. Within the usingblock, the object is read-only and cannot be modified or reassigned.

The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler.

Also, do you know that a using statement is expanded by the compiler to a try{..} finally{..} block at compile time? Read more tips about using statement in MSDN.

3. Not unhooking event handlers appropriately after wiring them.

I think Scott Langham brought up a great point about not unhooking event handlers. People don’t really ‘remember’ to unhook events.

In C#, when you register an event handler, you are creating a strong reference from the event source to the listener. So, the listener won’t get garbage collected even if you don’t have any pointers to the listener - unless you unhook the event by yourself, and this might even result in a memory leak.

So, if you are thinking about how to deal with situations where your  Source is having a longer life span than the listener – there are multiple ways to deal with it, and Daniel Grunwald covers them nicely in this excellent Codeproject Post.

4. Forgetting that Strings are immutable

In .NET, we know that strings are immutable – which means, once a string is created, its value can’t be changed. All string operations you perform, actually returns a new string containing the modification.

John Sonmez have a nice point with an example.

5. Not Overriding GetHashCode when overriding Equals method in C#

Why this is important? If Hashcode of two items does not match, they’ll be never considered equal, and the Equals method will never be called to execute your custom comparison logic – let us say, in scenarios where your objects are used as a key in a dictionary or so. Hence, in first place, you should override GetHashCode and return the same value for two equal objects based on comparison logic. I’ve seen this a couple of times during code review.

So, though Mark Gravell has several interesting points in his answer, my pick is about not overriding GetHashCode when you override Equals method in C#.

 

You may read my other Back To Basics posts here, you may find them interesting.

 

Note: As mentioned, these are my favorite picks of common problems, with some custom commentary. I suggest you to go through the entire thread here in Stack Overflow if you are interested. Happy coding!!