With such approach if we create a new class or even if we change a single line in some old file - we MUST write a full documentation for this file. But can we use it for our regular projects? Sure we can, especially when we write our logic as an external library included by the main project. Self-explanatory code approach does not work without code review we always document a class interfaceĭocumentation for classes is a standard for libraries and frameworks. This is where your reviewer comes into the play: he reads your code and if he cannot understand it - you should either refactor or add a comment which describes particular lines. Because you always understand your own code, especially when it is freshly written. But this idea does not work without code review. As soon as you change something in the file you must review the whole function or even the whole file.Įach time we see that code is not self-explanatory - we refactor it. The main reason for such decision: it is really hard to keep in-code comments up-to-date. we usually do not comment the code itself Below you can find main principles of code documentation we use on real C++ project. C++ projects documentation best practicesĬ++ is not the best language for reading especially when it comes with extensions provided by Qt, JavaScript or slowly-dying target system environment, so we had to find a way to improve readability and ensure that new developers will have a low start with the project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |