One of the qualities that distinguishes code-and-fix hacking from software craftsmanship is a different idea of what "done" means.
If you are hacking , the primary goal is to create something that seems to work. If you are a craftsman and you want to create something that may endure, something you can be proud of, that is only part of the story. The XP Simplicity Rules express the difference very well. According to these rules, simple code:
- Runs all the tests.
- Expresses every idea that we need to express.
- Says everything Once and Only Once.
- Has no superfluous parts.
In other words, it works. More than that, it demonstrably works because there are tests and they pass. This is a higher bar than just "working".
This encompasses many aspects of good coding hygiene: The architecture is suited to the job it does. Classes have clear responsibilities. Methods and varibles are named appropriately. Comments explain the tricky parts.
BTW a good rule about comments is this: Whenever you think you need a comment to explain something, consider putting the code that would follow the comment into a subroutine with a good name. That way the comment may not be needed and the code will read more clearly.
I have written about this in this essay - I won't repeat myself here :-).
Take out the cruft! If it's not needed to fulfill the current requirements, get rid of it! Don't worry about keeping stuff you might need later, you can always dig it out of source-code control and put it back in. Comment it out for a while if you must, but after a while rip out the comments.
"Perfection, then, is finally achieved, not when there is nothing left to add, but when there is nothing left to take away. " --Antoine de Saint Exupery