Doxygen: Difference between revisions
Lou Montana (talk | contribs) (Add Class documentation info + Examples) |
Lou Montana (talk | contribs) (Fix "what is not documented does not exist" (from Arma 3: Writing a Function), Fix comment style priority) |
||
Line 7: | Line 7: | ||
}} | }} | ||
{{Feature|important|What is not documented does not exist!}} | {{Feature|important|2= <div style="font-size: 1.25em; text-align: center">What is not documented does not exist!</div>}} | ||
Line 28: | Line 28: | ||
{{Name|bi}} recommendations: | {{Name|bi}} recommendations: | ||
* use {{hl|/*! */}} | * use {{hl|//!}} and eventually {{hl|/*! */}}; {{hl|///}} and {{hl|/** */}} are to be avoided. | ||
* do not go too much into details (e.g <enforce inline>//! This method does xxx if provided Y but will not do it if Z is set to true at line 246 and ...</enforce>) | * do not go too much into details (e.g <enforce inline>//! This method does xxx if provided Y but will not do it if Z is set to true at line 246 and ...</enforce>) | ||
* do not over-document code (<enforce inline>m_iVar++; // increments m_iVar by 1</enforce> is of absolutely no value) again, code should be self-explanatory and a comment should explain a design decision (if needed) | * do not over-document code (<enforce inline>m_iVar++; // increments m_iVar by 1</enforce> is of absolutely no value) again, code should be self-explanatory and a comment should explain a design decision (if needed) | ||
Line 44: | Line 44: | ||
Grouping is usually done in a different comment block than class comment. | Grouping is usually done in a different comment block than class comment. | ||
<enforce> | <enforce> | ||
/ | //! This class is a databag used by the TAG_WholeSystemClass's WholeSystem feature. | ||
This class is a databag used by the TAG_WholeSystemClass's WholeSystem feature. | //! Member variables are public for that purpose. It holds info X and Y related to Z. | ||
Member variables are public for that purpose. It holds info X and Y related to Z. | |||
class TAG_MyDataClass | class TAG_MyDataClass | ||
{ | { | ||
Line 66: | Line 64: | ||
{ | { | ||
//------------------------------------------------------------------------------------------------ | //------------------------------------------------------------------------------------------------ | ||
/ | //! Documentation goes here with the same indent | ||
int GetIntMethod1(bool returnPositive) | int GetIntMethod1(bool returnPositive) | ||
{ | { | ||
Line 75: | Line 71: | ||
//------------------------------------------------------------------------------------------------ | //------------------------------------------------------------------------------------------------ | ||
/ | /*! | ||
Alternative syntax | |||
*/ | |||
int GetIntMethod2(bool returnPositive) | int GetIntMethod2(bool returnPositive) | ||
{ | { |
Revision as of 17:20, 16 June 2023
Doxygen is a tool that generates documentation from code comment respecting a certain format. This code documentation is used across Enfusion projects, starting with Arma Reforger.
Project Documentation
Bohemia Interactive Guidelines
Documentation is important:
- Document what is public (protected methods go second - people should use public methods anyway)
- Document what is important (features, concepts, specifics like variables or constants, etc)
- Document what is dangerous (performance-wise, crash-wise)
Bohemia Interactive recommendations:
- use
/ /! and eventually /*! * /; / / / and /** * / are to be avoided. - do not go too much into details (e.g //! This method does xxx if provided Y but will not do it if Z is set to true at line 246 and ...)
- do not over-document code (m_iVar++; // increments m_iVar by 1 is of absolutely no value) again, code should be self-explanatory and a comment should explain a design decision (if needed)
Class
A class documentation explains what the class does. It can add said class to groups (see Doxygen's grouping documentation). Grouping is usually done in a different comment block than class comment.
Method
A method documentation goes below the
Various parameter formats:
Only one return format:
To be used when a void signature is not used.
Variable
Examples
Do
This example is taken from SCR_ObstacleDetector:
This comment is fine for multiple reasons:
- the main description states the method's goal and usage condition
- parameters are documented and specifics (when present) are explained
- the return value is described accurately
- error cases are covered
Don't
Example | Explanation |
---|---|
| |
//------------------------------------------------------------------------------------------------
//! Returns true if has obstacle
//! \param worldPos the world position
//! \param exclusionList the exclusion list
//! \return true or false
bool HasObstacle(vector worldPos, array<IEntity> exclusionList = null) |
|
This one is one of the worst possible cases: no comment is better than a wrong comment. |
See Also
- https://www.doxygen.nl/ - the official Doxygen website
- https://www.doxygen.nl/manual/ - the official documentation