How to write comments and an introduction to CDD

Read the following wikipedia page :

Written well enough for me 🙂

about using TODO, here is an example:

// TODO:2008-12-06:johnc:Add support for negative offsets.

// While it is unlikely that we get a negative offset, it can

// occur if the garbage collector runs out of space.


see that the todo tag is followed by date then developer name, as it will help other developers to understand who is writing this todo and why.

level of details: The level of detail in the documentation is an important element. Too much detail renders the documentation ina ctive; rather the tool should generate documentation as intended by the author and not as produced by an exhaustive parsing tool.

alright, lets talk about comment driven development (CDD). Comment programming, also known as comment-driven development (CDD) is a software development technique that is based on the regular use of comment tags. In comment programming the comment tags are not used to describe what a certain piece of code is doing, but rather to stop some parts of the code from being executed. The aim is to have the commented code at the developer’s disposal at any time he might need it. This is especially useful when the requirements change rapidly. In this case they happen to revert to older versions of themselves, thus making the programmer either write the code again, or revert parts of the code from the versioning repository, which would be more time-consuming. With comment programming, when such a request for reverting to an old implementation arises, the developer just comments the current implementation and uncomments the previous. It is advisable to add short descriptive comments to blocks of commented code.

another good definition i found: This is a programming methodology that encourages the developer to start out complex projects by building a wireframe of their procedures using little more than comments – and basic pseudocode – to describe each step of the algorithm. CDD helps the developer encounter and work out problems before they write a line of actual code; it also has the advantage of helping clearly delineate the routes between the high-level problem and the many small-picture fractals it is composed of. The comments created using CDD may survive the process of actual coding and development as line comments throughout the programming unit; however, it will sometimes make sense to delete them after their purpose has been served. (better then wikipedia i hope)

here is the video from MSDN sweden, hope that helps you, will write more about it.

reference and read more: (a good article, i would suggest you to read it)