Messy Code

[ThePentiumGuy]

Ever work on a project and find out that the code was messy? And when you start cleaning up the code the project doesnt work?

What do you guys do to keep your code neat? Im a horrible organizer so ... youll 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

 

[Himo]

Yup, Im a slob too. If not asked for, I dont comment most of my code and the IDE luckily does the indentation for me, because I wont

 

[PlausiblyDamp]

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...

 

[wyrd]

Read this book and youll never have "messy" code again:

http://www.amazon.com/exec/obidos/A...05/sr=2-1/ref=pd_ka_b_2_1/002-9860937-2800811

 

[mocella]

Or like PlausiblyDamp hinted at - Refactoring. Check out Martin Fowlers book on the subject - its got a lot of good ideas as well as samples on how you go about refactoring out problems with your(or others) code.

Ive 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 - weve all been there when trying to clean up (not change, just sort of organize )one thing and all the sudden nothing works. My solution to this is frequent check-ins as you successfully fix each issue youre working on (unless your environment doesnt allow for this in which case Id load CVS on my own machine to version the stuff locally at minimum).

 

[Napivo1972]

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

 

[ThePentiumGuy]

Heh. Thanks guys . Thanks for the book recommmendations too.
Yeah when I get messy code I usually redo everything from scratch and I end up fixing hundreds of problems that way.

-TPG

 

[samsmithnz]

I think everyone used to have messy code. This changes (I hope) when you have to inherit someone elses code and realize that if theyd commented the code your job would be a lot easier.

Im 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, youll be much happier and prouder of your work, especially when you know someone else has to use it...

 

[wyrd]

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 were 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 isnt absolutely necessary, and is probably still getting in the way:

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

Point being, dont get zealous with commenting. If you program your code well enough, itll document itself. Thats the true sign of great design and programming. But dont take this too far, either, or misunderstand what Im saying. Too little commenting is also harmful. You want to comment where possible, you just dont want to repeat what the code already says by itself.