|
Code Documentation - This is what I think many programmers think of with the word documentation. This writing is highly technical and is mainly used to define and explain the API's and data structures. E.g., to spell out that the variable "m_name" refers to the first and last name of a person. Often, one will inline this kind of documentation within the source code, thereby allowing a tool such as Doxygen? to auto-generate the code documents. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class. |
|
Code Documentation - This is what I think many programmers think of with the word documentation. This writing is highly technical and is mainly used to define and explain the API's and data structures. E.g., to spell out that the variable "m_name" refers to the first and last name of a person. Often, one will include this kind of documentation within the source code, thereby allowing a tool such as Doxygen? to auto-generate the code documents. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class. |
|
Architecture Documentation - This is a special breed of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first.) Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existance of such a routine. A good architecture document is short on details but thick on |
|
Architecture Documentation - This is a special breed of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first.) Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on |
|
-- BryceHarrington |
![[Home]](wikipedia.png)