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 pastures and move from one job to another, 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 goal of the documentation should be made available to the 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 Technology used should also be explained in-depth to enable programmers to 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 newcomers to the company find it easy to read and understand within the shortest time possible. Very little difficulty should be met in trying to understand what the documentation is meant to do. Documentation should be done in real simple language 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 a 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 every day 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 a while, we simply cannot remember the same reason some things are the way they are.
Some points to use for proper code documentation are stated as follows:
- Use descriptive names for variables, methods, functions, and classes. Kindly make sure that the wordings used to give the exact 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.
- Discussion sessions can be held to bring every member of the team up to step of the current progress and other issues about the team.
The whole idea of documentation is to know exactly what is to be achieved and to understand the context in which the programmer is trying to meet a certain goal.
As more awareness is made about documentation, the idea of documentation would not be seen as a burden but as a necessary way of programming.
Red Hat Software Collections are available for download, you can read more at Red Hat Software Collections.
Last updated: March 9, 2017