In programming, documentation is not only about documenting our code, but also the steps, processes and architecture around how things work. We are most familiar with documentation from the aspect of the code, which is something that should be encouraged. But as developers look for greener pasture everyday, the idea of documenting every aspect of programming is important so that the effect of the bus factor does not set in for any organization when a programmer decides to leave.
To decide how to document, the entire aim and objective of the documentation should be made available to the whole team. Sometimes, when we do not know the goal of a process, we seem to behave in a different way. To be able to document, every member of the team should have a full knowledge of the aim of the documentation so that everyone is in the loop and when a mistake is made, everyone can quickly realize the mistake and make necessary suggestions.
The current technology been used should also be explained in depth to enable programmers see the bigger picture of the technology. Sometimes, when we do not understand a certain technology, we begin to use it in ways not originally designed and mostly undermine the major purpose of the technology.
After a proper understanding of why the documentation is needed and the technology to be documented is understood, then comes the main documentation process. Documentation should be such that new comers to the company find it easy to read and understand within the shortest time possible. Very little difficulty should be faced in trying to understand what the documentation is meant to do. Documentation should be done in real simple English so that another task of looking for the writer of the documentation to explain some things are not introduced.
By having processes documented, the most important documentation that comes up next is code documentation. The aim of code documentation is to have clean and clear code. A code is said to be clean and clear if the person reading the code does not need further information from the writer of the code to understand exactly what the code does. As programmers, we solve different problems everyday and once a certain problem is solved, we close that case and move on to other bigger cases. So when we are drawn back to explain certain solutions to some problems after sometime, we simply cannot remember the same exact reason why some things are the way they are.
- Some points to use for proper code documentation are started as follows:
Use descriptive names for variables, methods, functions and classes. Kindly ensure that the words used give the normal meaning of what they are instead of using ambiguous words. The length of the wordings should not be a barrier in writing good namings.
- Ensure to use few lines for a method. A longer method or function might be difficult to follow through, rather make the number of lines short enough to follow. By this, the method can be broken down into different methods.
- Follow the rules and standards for documentation. There are general and conventional rules for documentation and these should be followed at all time. Deviation from the general rule can most likely create chaos and other unwanted problems.
- If it becomes more like a problem writing documentation, recordings can be introduced to help understand the state of mind of the programmer when writing certain code.
The whole idea of documentation is to know exactly what is to be achieved and sometimes know the state of mind of the programmer when trying to achieve a certain goal.
As more awareness is made in documentation, the idea of documentation would not be seen as a burden but as a necessary way of programming.
Ensure that your friends and colleagues document their codes, because if they don’t, you might be working on that code tomorrow and you would wish it was documented.