Writing solid code is more than good intentions; it also entails defensive programming. Defensive programming is a proactive approach to diagnosing and preventing software problems and bugs. It provides a framework that enforces consistent programmer discipline to write quality code.

Problems discovered at compile time are easier to fix and less expensive to resolve. One problem is that unit testing is not guaranteed to isolate all runtime problems. Furthermore, unit testing tests features, user interface, usage patterns, and more, but most often it does not test individual lines of source code. Therefore, the responsibility of writing solid code remains firmly with the developer and not the tester. Best practices such as raising the warning level to four; treating all warnings as errors; and applying appropriate modifiers to classes, methods, and other entities moves the discovery of possible software problems from runtime to compile time.

Code is not perfect and must be revisited on occasion. This is typically the role of the maintenance programmer. Documentation documents code for the maintenance programmer and yourself. Documentation can be accomplished in several formats. For example, UML diagrams created for software modeling can document an application. You can also document code with pseudo code. Finally, you can add conventional comments. Self-documenting code mitigates the need for extensive comments.

Programmers create errors. No program is innately error prone. You place errors in the application. Independent reviews are helpful in finding programmer mistakes. Code reviews and unit tests are the best techniques for finding these kinds of problems. Automated unit tests are particularly useful for consistent and comparative results. Testing is only as effective as code coverage. You should strive for 85 to 90 percent code coverage. Remember, code that is not touched is not tested. For 100 percent code coverage, consider test-driven development (TDD). With TDD, you create the test first, which will fail. You then write the code to make the test pass.

Design patterns provide known, as well as tested, solutions for established software problems. The solutions are published as patterns and are not generally environment or language specific. Wherever possible, use patterns when available for a specific problem. This will help you create quality code quicker.