A recurring topic in every project I’ve been involved with is when and where you should use XML comments and/or annotate classes and members with proper documentation. Having played around with the Squidex code base the last three weeks, I see the same challenge.
I’ve always been very specific about this, but in real live I meet a lot of developers who don’t seem to care about this, or worse, they reject the entire concept. Some of these people claim that the only real documentation is the code itself. And although I fully agree that a well-factored and properly named class is a crucial element in achieving a maintainable code base, proper documentation is just as important.
In my opinion, these three kinds of documentation are required for every professional code base, including that of Squidex
Class-level and member-level documentation helps you understand what behavior to expect without having to jump into the actual implementation details. It should also explain the responsibilities and the roles the class plays in the overall design, or the member within the class. This kind of documentation is not a replacement for proper naming. Both are crucial, and one should reinforce the other. So always document the expected behavior of all your public and protected members. But, don’t add documentation that repeats the name of the member. I’d rather have no documentation at all than that kind of useless crap.
Inline comments, which you should use scarcely, are there to help you understand the thought process the original developer went through, to point you in the right direction, or to emphasize a particular non-trivial design decision. I use the word scarcely purposely, because in most cases, refactoring the code can help you avoid the need to have in-line comments. For instance, wrapping a complex expression in a method which name explains the goal of the algorithm can already make your code a lot easier to understand.
Commit comments should not only explain the nature of the change, but more importantly, why a particular change was needed in the first place. When a lot of people are involved, it becomes pretty important to be able to see why something that happened a long time ago happened. Yeah, an internal blog can help, but ultimately, it’s the source control history that will contain the really interesting changes. I’ve seen numerous occasions where I noticed some code that seem to be superfluous, but ended up being quite critical. The commit message for that change helped me understand why. Unfortunately I’ve also seen less helpful commit messages requiring me to figure out the reason the hard way.
Don’t get me wrong, Squidex looks extremely promising and may be exactly what we’re looking for, but I’m quite concerned about the lack of code documentation. Hopefully my little wall of text can convince you to change your development mindset.