I'm smarter than the Runtime!

One of the great features of .NET is the automatic garbage collection that absolves the developer of worrying about C++ style memory management, where for every allocate, there must be a destroy, or you're leaking. And yet, I frequently see overzealous developers write code like this:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/07/im-smarter-than-the-runtime.html

Hi Paul, I found your post on this topic

http://weblogs.asp.net/pwilson/archive/2004/02/20/77435.aspx

This brings up a good point. Objects that NEED to be disposed (GDI, files, etc), should have some special visual flag or even generate a “squiggly line” IDE warning when they are NOT disposed in a code block that they just scoped out of.

There seem to be two classes of objects: 1) the common type that can just be GC’ed, 2) the type that require cleanup. I think the distinction is lost on most developers, frankly, and needs to be highlighted by the IDE somehow. If the class implements .Dispose(), then that seems like an easy/obvious way to flag…

http://weblogs.asp.net/pwilson/archive/2004/02/14/73033.aspx

“My sample also calls the Clear method, and Dispose when its defined, but separate
tests actually showed they actually did not make a difference – just set to null.
That said, a colleague has convinced me that not calling Dispose when its defined
is just asking for trouble, afterall why is it defined if not for a good reason.”

I think the real lesson here is, don’t take anything as gospel, even “best practices” of calling Dispose() – MEASURE IT YOURSELF and see what is necessary for your application. I’d also add to that, always take the default behavior unless you have a VERY good reason not to, backed by actual data like what you provided in your blog entry (eg, "setting my objects to null keeps the private bytes level at
100MB ").

Paul, great blog entries! Index here:

http://www.moskalyuk.com/blog/archives/000046.html

Here is a good reason : in some companies, code is valued according to the number of lines produced. Of course, perl is highly diregarded in such places, while manual memory management becomes the mark of an “above average programmer”.

I have three words for those developers: Obsessive-Compulsive Disorder.

I agree that you shouldn’t be setting objects to null (or nothing in VB) unless you really have a damn good reason (and they do exist), but I have to disagree on the dispose. The only objects that should have a dispose method are those that have a reason to have one – like the files, database connections, and GDI handles. Thus, if there is a dispose method, then you best be using it, and you should wrap it in a try/finally or a C# using block to be sure. True, for those clever enough to decompile things there are some objects with dispose that don’t really need them (like the dataset), but you’re starting a very dangerous trend if you go down that path. Why? Maybe it will be needed in the future, or maybe someone else maintaining the code won’t be so smart – is it really worth trying to know better than the pattern that exists for a very good reason. And don’t assume that gurus, articles, books, or even MSDN are always correct when they tell you that you don’t need a dispose either, since there are a lot of myths that keep getting recirculated here. So while I agree you should typically let the GC do its work (by not setting objects to null), the dispose method exists because the GC won’t do all the work in some cases!