Only the Code Tells the Truth
The ultimate semantics of a program is given by the running code. If this is in binary form, it might not be easily read. However, the source code should be available if it is your program. Looking at the source code the meaning of the program should be apparent, since this is the only relevant thing to look at. Even the most accurate requirements document does not tell the whole truth, since it does not contain the detailed story of what the program is actually doing, only the high-level intentions of the requirements analyst. A design document may capture a planned design, but it will lack the necessary detail of the implementation and may have lost its link with the current implementation. Furthermore, these documents may never have been written in the first place, or may have been lost by the time the code needs to be changed in the future. The code may be the only thing left.
Ask yourself, how clearly is your code telling you or any other programmer what it is doing?
You might say, "Oh, my comments will tell". But keep in mind that comments are not running code. They can be just as wrong as other forms of documentation. There has been a tradition saying comments are unconditionally a good thing, so some naive programmers started to write more and more comments, even explaining trivia that is said by the code to a professional programmer. That is wrong. If your code needs comments, consider refactoring it so it doesn't. Lengthy comments can clutter screen space and might even be hidden automatically by your IDE. If you need to explain a change, do so in the version control system check-in message and not in the code.
What can you do to actually make your code tell the truth as clearly as possible? Strive for good naming of program elements. Structure your code with respect to cohesive functionality, which also eases naming. Decouple your code to achieve orthogonality. Write automated tests explaining the intended behaviour and check the interfaces. Refactor mercilessly when you learn how to code a simpler, better solution. Make your code as simple as possible to read and understand.
Treat your code like any other composition, such as a poem, an essay, a public blog, or an important email. Carefully craft your expression, so that it does what it should and communicates as directly as possible what it is doing, so that it still communicates your intention when you are no longer around. Remember that useful code is used much longer than ever intended. Maintenance programmers will thank you. And, if you are a maintenance programmer and the code you are working on does not tell the truth easily, apply the guidelines above in a proactive manner. Establish some sanity in the code and keep your own sanity.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page