Messy Code

T

ThePentiumGuy

Senior Contributor
Joined
May 21, 2003
Messages
1,113
Location
Boston, Massachusetts
Ever work on a project and find out that the code was messy? And when you start cleaning up the code the project doesn't work?

What do you guys do to keep your code neat? I'm a horrible organizer so ... you'll see half the code commented, half the comments saying "THIS DOESNT WORK" or "IF YOU UNCOMMENT THIS LINE, THEN YOU NEED TO CHANGE THIS OTHER LINE TO <something else>".

I think it just takes some dedication and patience I guess.

-The Pentium Guy
 
Decent source code control is a must so you can always back out of any breaking changes.
Frequent code reviews or refactoring can help by having 'problem areas' identified earlier and hopefully fixed before the issues get to ingrained into the code base. If you find you have to propagate changes over several places then take a step back and look to see if you could consolidate some of this code in to a method / class.
One of the biggest incentives is to work on a project of any size and then come back to it a few months down the line - badly organised, badly commented code becomes an utter nightmare; even if it seemed to make sense when originally written.
A bit of time spent commenting etc as the code is written will save a lot of time when you need to debug, maintain or repair...
 
Or like PlausiblyDamp hinted at - Refactoring. Check out Martin Fowler's book on the subject - it's got a lot of good ideas as well as samples on how you go about refactoring out problems with your(or others') code.

I've had a lot of luck using the test first approach to develop (TDD) over the past year or so. So, not only is all my code supported with unit tests, my functions hardly ever reach more that 10-15 lines of code. This kind of ties in with the refactoring topic - get it to work, then break down to the lowest units of work and these all become their own functions.

To ThePentiumGuy - we've all been there when trying to clean up (not change, just sort of organize :cool: )one thing and all the sudden nothing works. My solution to this is frequent check-ins as you successfully fix each issue you're working on (unless your environment doesn't allow for this in which case I'd load CVS on my own machine to version the stuff locally at minimum).
 
He he same here. One sure way of learning once and for all is taking a VB6 project from a year or 2 ago and transfer it to .net. I am currently doing that for one of mine and I learned my lesson.

I basically made a new analysis to get it done and I am rewriting the code from scratch…..

This time no 2 lines are uncommented.
 
Heh. Thanks guys :P. Thanks for the book recommmendations too.
Yeah when I get messy code I usually redo everything from scratch and I end up fixing hundred's of problems that way.

-TPG
 
I think everyone used to have messy code. This changes (I hope) when you have to inherit someone else's code and realize that if they'd commented the code your job would be a lot easier.

I'm very careful about commenting as much as possible as early as possible. I know that at the end of a project there are always weird tweaks, but if the bulk of the application is commented, you'll be much happier and prouder of your work, especially when you know someone else has to use it...
 
Too much commenting can make code harder to read. The best code documents itself.

Example:

Bad:

// Check if a player is dead.
if (player.IsDead) { ... }

Obviously the comment does nothing but repeat the code. In this case, the comments get in the way and would be better off left out, or a more meaningful comment needs to be put into place.

Good:

if (player.IsDead) { ... }

or explain why we're checking if the player is dead:

// Death animation must be displayed when the player is dead.
if (player.IsDead) { player.BeginAnim(ANIMATION_DEATH); }

Even so, the code still speaks for itself, so the comment still isn't absolutely necessary, and is probably still getting in the way:

if (player.IsDead) { player.BeginAnim(ANIMATION_DEATH); }

Point being, don't get zealous with commenting. If you program your code well enough, it'll document itself. That's the true sign of great design and programming. But don't take this too far, either, or misunderstand what I'm saying. Too little commenting is also harmful. You want to comment where possible, you just don't want to repeat what the code already says by itself.
 
Back
Top