.NET and sloppy coding
-
.NET managed code seems like a good idea at first, but doesn't the idea of the garbage collector sweeping up after you encourage sloppy programming?
What are your views?
-
It does indeed but many view that as a plus since novice users have more empowerment at this and should mean that developement groups can do more use the WYSIWYG interface to accomplish things faster. However in the garbage collector misses things, especially optimizations that could speed things up or shrink the code down. It encourages not only sloppy coding habits but more inline process building that object oriented programming.
-
3 steps forward 2 steps back then
One thing I am not clear on with garbage collection (whether in Java, .NET etc) is when is it a good idea to destroy references to objects?
I have always worked on the principle that you should destroy objects as soon as possible.
I have been told by several programmers that it doesn't really matter and that garbage collection simply runs when it does.
I understand that garbage collection (like sh*t) just happens, but surely if you destroy objects ASAP garbage collection is going to more effective?
-
Destroying objects manually ASAP is best method.
This frees up memory and unloads DLL's earlier.
-
However there are some times when destroying may be too early and much garbage collection code (not all and only around many things like ADO which seem to have a when is it best ? mark beside it) has been written to be more effective. Previously it was much less so.
-
This is not the case, though, in .NET. Even when you destroy an object (by disposing it if it supports .Dispose, or setting it's value to Nothing) the object does not get destroyed right away. All that does is simply inform the garbage collector that you are no longer referencing it, so when it runs next, it may or may not destroy the object.
-
I'm sorry, but I don't see the connection between sloppy coding habits and having a garbage collector. Can you please elaborate? Personally, I find that not having to worry about the minutiae of memory management makes my code a lot cleaner.
The garbage collector (in .NET at least) doesn't absolve you of all responsibilty, and in some cases one must override its behavior when dealing with some types of resources (e.g. files). But, on the whole. I heartily disagree that it encourages sloppy coding. Rather, it makes my code much cleaner and much less prone to subtle and annoying bugs.
-
While I am grateful for MS adding the garbage collection, I do believe it encourages sloppy or programming of a lesser quality and to be totally honest it is more of a which came first--the chicken or the egg type of a question.
Anyhow, one of my developers said the other day in a metting that he didn't have to worry about any of that anymore because the garbage collector would take care of it for him. Bet you can't guess who will have very restricted access in the next version of SQL (Yukon).
SJ
-
The key thou is the garbage collector only does so much. Some objects can be created and because they are not set to a specific condition the collector doesn't even know they can be cleaned up yet and thus we have memory leaks and even buffer overruns that appear in an app. You hear of Java code all the time that is not cleaning up the way it should. Most times it isn't the garabage collectors fault but the programmer. The I don't have to do that becaue the garbage collector will get it mentality is poor because eventually you will have something yo need to do that the collector doesn't handle. Also just because you write it doesn't mean your code is great, many people rely on the WYSIWYG features of InterDev and FrontPage but in both cases I can strip about 40% of the code out that it puts in as it is just filler in most cases. Sloppy coding comes from too many people who don't have a clue and are not willing to properly learn how something works that are given a tool to throw something complex together in a simplke fashion. They will make changes and changes and changes not realizing they left variables and objects decalared and created from these changes that aren't even used, or whole functions, or classes and thus the code is bloated with unintended slop.
Garbage in garbage out still applies even with .NET.
-
OK, it sounds to me like what you're really saying it's not the garbage collection per se that encourages sloppy coding, but rather sloppy programmers who don't know how to use their tools properly?
I'm not sure where you hear "I'll just let the garbage collector deal with it" but you'll never hear me saying it. Seems to me like what you're really arguing about is the difference between amateur/novice and professional/experienced programmers. The problems you describe are not endemic to any particular tool but rather, IMOP, reflect lack of experience with the tools and with programming/development in general. I would expect more experienced developers to be less likey to have a "I'll just let <x> deal with it" mentality.
I can certainly agree, though, about how modern tools can encourage sloppy behavior. They tend to hide the details of what's going on, which can be bad.
-
Yes, that is what I am saying and I think the originator is getting at. .NET is a framework and in essence is not the root of the problem but the newer developement IDE seem to focus on quantity and not quality. They present themselves in such a way that any novice or amatuer could work in a shop just by saying I know .NET. The WYSIWYG is a crutch to too many developers IMHO. I actually met a guy who wouldn't hire me just because I said I prefered notepad or source view as an html editor over the drag and drop interface of InterDev and .NET VB. I tried to explain I prefer to be more in touch with my code and how well it works. He just said he wants somebody who uses the tool provided and can roll out quick. Duh, whatever happened to software QA, seems to be a thing of the past "fix it in next version".
-
A good tool makes a hell of a difference to the productivity.
I don't like the way Interdev and Frontpage bloat the code, and yes, I too used notepad for web work until I discovered the Zend IDE for PHP and Dreamweaver for HTML.
I like Dreamweaver even though it does add some superfluous baggage.
As far as I am concerned, not cleaning up your coding objects after you is a bit like leaving your underwear on the floor of your bedroom and expecting the wife to pick them up. Not a good idea. Those of you who are married will know EXACTLY what I mean.
IMHO the garbage collector should be viewed as a safety net, not a crutch.
I found that when I taught myself C++ it made me a much better VB programmer and I thoroughly endorse the view that knowing what goes on behind the scenes is important.
We use a number of web content management systems here and for the most part they work fine, but it can be very frustrating when you want to push the limits and your lack of knowledge of what goes on under the hood makes the programming a hit and miss affair.
-
I am also a self taught C++'er. In fatc my first project in it was the reason I learned it. It is a server and a client. The entire client GUI was built in C++ by me mostly via code so I do agree. Even the good developers should get more intimate with their code and truely understand what they are doing.
-
While I am not a C++ programmer (VB is in my blood since v3), I am most worried about the the .NET stuff moving down inside the DB in the next version and the problems that this will cause for performance tuning and management. Not only will I have to tune the DB, now I will have to be aware of their VB or C# code.
-
Why tempting any bugs in the decision strategy of the garbage collector? You can sick the sodding thing on any objects you want to waste (set a=nothing) .
Accepting all invitesViewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply