Relating this to recent projects involving updates and additions to other people's code, it reminds me of ways to both test legacy code and document my own.
in reply to Seven habits of highly careful coders
In testing legacy code:
- Is it still in use? If not, why?
- What's the scope? Exactly where will this work and where will it fail?
- Is the author still around so I may ask questions?
- Is it worth figuring this out and updating it, or would I be better off starting over?
In documenting my own code:
- What does this code do and why was it created?
- Include a history section that documents changes and dates.
- Add a simple outline if it's complex so it's easy to understand it without studying all the code.
- Document the code assuming you'll be trying to understand it two years in the future and you don't remember anything about it.