A colleague and I attended a 2 day Clean Code workshop last year with the man himself, Uncle Bob, and while I learned a lot about what constitutes 'clean code' I must say that the biggest takeaway item I got was this:
The Boy Scout Rule (for programmers): Check in your code a little cleaner than you checked it out (Clean Code - Page 14)
The realisation that by doing this this every time we committed new work we are actively reversing the rot was no small boost in confidence. Knowing you're driving your codebase to better things every day was, and still is, a huge motivator for the whole team.
So, my question to the readers is: Do you follow the boy scout rule?
It depends on the code. Some code is clear enough so that you can at least see where there might be a problem, in which case I'll try to fix it if it's reasonable to do so in the time before my manager demands results from whatever task I was supposed to be doing in the first place.
But some code is just so awful or complex that you simply have no idea where to start, or it's an area where you don't feel you know enough to improve it, in which case I'm afraid it's over to some other poor sod to fix it, unless I have enough time to investigate/learn/fix/test things properly.
It's a good rule to follow though, as it will also help you to learn a bit more about the code and - over time - make your own job easier as you start to use your new improved code instead of the nasty old crud you found there originally. And of course it allows you to give other programmers plenty of opportunities to follow the same rule by fixing your crud!
My wife is always telling me that she wishes that I'd put as much effort into cleaning up my office as I did in cleaning up code (mine and others'). Seems like cleaning up code is all I ever do nowadays. It's a crappy job but somebody's gotta do it. There's plenty of messy code out there and it seems like more messy code is written than is cleaned up, a discouraging thought to say the least. (wild-a$$ guess) 95% of the programmers I meet just don't care enough to write clean code or clean up after themselves. The trick is to pick your battles. I only insist on cleaning up code that is critical to completing the task at hand. Other messes that we see but won't be touching soon are left for another day.
It's a double-edged sword. While the urge to make the code better is strong, the risk of inadvertently adding regressions is real. Of course, that can be mitigated by having a good set of regressions tests -- but really, how many systems have you worked with that have decent regression coverage?
You raise an interesting point Bear. 'Cleaning up' production code without test coverage is risky, and often too dangerous to justify the perceived benefit. However, it is my view that the test suite is as important a part of the codebase as the production code itself so I would consider that writing a regression test for some uncovered code is a valid improvement even if you don't change the prod code.
You will get no argument from me on that point -- but in reality, how many places have you worked where test coverage is that good? My current contract (coming to an end soon) likely has the best test coverage of any system I've worked on, but it's still marginal at best. Most other places I've worked have zero test coverage, or at best, a handful of high-level tests.
Cleaning up code is always easier when it's backed up with a set of tests that you can rely on to break if you messed something up. That's why TDD is a very important practice for me -- when we do code cleanup, we always start with whatever unit tests are available. If there are none, we'll *try* to write some around the things we plan to clean up. Unfortunately, a lot of code is just too tightly coupled that it makes writing unit tests for them extremely difficult to impossible. This is where frustration builds up. Michael Feathers' WELC book has been a lifeline for me over the years as well as Joshua Kerievsky's "Refactoring to Patterns". In the worst case scenario, the only thing we end up doing to clean up the code is to do a few simple "extract method" and "rename" refactorings. Still, that's better than nothing.
You have to be odd to be #1 - Seuss. An odd little ad:
Free, earth friendly heat - from the CodeRanch trailboss