Doxygen: Difference between revisions
Lou Montana (talk | contribs) (Page creation) |
Lou Montana (talk | contribs) (Add Class documentation info + Examples) |
||
Line 1: | Line 1: | ||
{{TOC|side | {{TOC|side}} | ||
'''Doxygen''' is a tool that generates documentation from code comment respecting a certain format. This code documentation is used across [[Enfusion]] projects, starting with {{armaR}}. | |||
'''Doxygen''' is a tool that generates documentation from code comment respecting a certain format. | |||
{{Feature|informative| | {{Feature|informative| | ||
Line 14: | Line 12: | ||
== Project Documentation == | == Project Documentation == | ||
{{Feature|armaR|{{armaR}}'s Doxygen documentation can be found {{Link|{{SERVER}}/Doxygen/arma-reforger/|here}}.}} | {{Wiki|WIP|{{armaR}}'s Doxygen documentation is to be released and linked.}} | ||
<!--{{Feature|armaR|{{armaR}}'s Doxygen documentation can be found {{Link|{{SERVER}}/Doxygen/arma-reforger/|here}}.}} | |||
{{Feature|arma4|{{arma4}}'s Doxygen documentation can be found {{Link|{{SERVER}}/Doxygen/arma-reforger/|here}}.}}--> | |||
Line 25: | Line 24: | ||
* Document what is '''important''' (features, concepts, specifics like variables or constants, etc) | * Document what is '''important''' (features, concepts, specifics like variables or constants, etc) | ||
* Document what is '''dangerous''' (performance-wise, crash-wise) | * Document what is '''dangerous''' (performance-wise, crash-wise) | ||
{{Name|bi}} recommendations: | |||
* use {{hl|/*! */}} and {{hl|//!}}; format {{hl|/** */}} is 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 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) | |||
{{Feature|important| | |||
Reminder: an eventual '''code''' comment tells '''''why''''' code is done this way, | |||
'''method''' comment plainly explains '''''what''''' the method does / when it should be used, | |||
and '''class''' comment explains the whole system / feature of this class.<br> | |||
For a system / feature that spans across multiple classes, Doxygen grouping is required. See {{Link|https://www.doxygen.nl/manual/grouping.html|Doxygen Grouping}} documentation. | |||
}} | |||
=== Class === | === Class === | ||
A class documentation explains what the class does. It can add said class to groups (see Doxygen's {{Link|https://www.doxygen.nl/manual/grouping.html|grouping}} documentation). | |||
Grouping is usually done in a different comment block than class comment. | |||
<enforce> | |||
/*! | |||
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. | |||
*/ | |||
class TAG_MyDataClass | |||
{ | |||
bool m_bIsValid; | |||
int m_iNumber; | |||
ref TAG_OtherDataClass m_OtherData; | |||
} | |||
</enforce> | |||
=== Method === | === Method === | ||
Line 39: | Line 67: | ||
//------------------------------------------------------------------------------------------------ | //------------------------------------------------------------------------------------------------ | ||
/*! | /*! | ||
Documentation goes here with the same indent | |||
*/ | */ | ||
int GetIntMethod1(bool returnPositive) | int GetIntMethod1(bool returnPositive) | ||
Line 58: | Line 86: | ||
<enforce> | <enforce> | ||
//! \param myParam parameter description | //! \param myParam parameter description | ||
//! \param | //! \param[out] myParam parameter description | ||
//! \param | //! \param[inout] myParam parameter description | ||
</enforce> | </enforce> | ||
Line 66: | Line 94: | ||
//! \return return value description | //! \return return value description | ||
</enforce> | </enforce> | ||
To be used when a <enforce inline>void</enforce> signature is not used. | |||
=== Variable === | === Variable === | ||
Line 73: | Line 102: | ||
protected float m_fVar1; | protected float m_fVar1; | ||
protected float m_fVar2; //!< or like this - the '<' symbol | protected float m_fVar2; //!< or like this - the '<' symbol means "document what just precedes" | ||
</enforce> | |||
== Examples == | |||
=== Do === | |||
This example is taken from {{Link/Enfusion|armaR|SCR_ObstacleDetector}}: | |||
<enforce> | |||
//------------------------------------------------------------------------------------------------ | |||
//! Detects obstacles based on current settings - a SCR_ObstacleDetector.RefreshObstaclesBy*() method must have been called earlier | |||
//! \param worldPos the location to check - only the 2D position will be checked | |||
//! \param exclusionList list of entities that should not be considered as obstacles | |||
//! \return true if an obstacle has been detected or on error, false otherwise | |||
bool HasObstacle(vector worldPos, array<IEntity> exclusionList = null) | |||
</enforce> | |||
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 === | |||
{| class="wikitable" style="width: 100%" | |||
! Example | |||
! Explanation | |||
|- | |||
| <enforce> | |||
//------------------------------------------------------------------------------------------------ | |||
//! Returns true if has obstacle | |||
bool HasObstacle(vector worldPos, array<IEntity> exclusionList = null) | |||
</enforce> | |||
| | |||
* the description is straightforward but does not provide context | |||
* parameters are not described | |||
* return value is included in the description and only covers one case (when everything works) | |||
|- | |||
| <enforce> | |||
//------------------------------------------------------------------------------------------------ | |||
//! 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) | |||
</enforce> | |||
| | |||
* the description is still straightforward without context | |||
* parameter descriptions are based on their name and do not help understanding further | |||
* the return value's description describes the value itself and not the added value | |||
|- | |||
| <enforce> | |||
//------------------------------------------------------------------------------------------------ | |||
//! Returns false when an obstacle is detected | |||
bool HasObstacle(vector worldPos, array<IEntity> exclusionList = null) | |||
</enforce> | </enforce> | ||
| | |||
This one is one of the worst possible cases: '''no comment is better than a wrong comment'''.<br> | |||
Prefer leaving it undocumented (ideally with a TODO) if you do not have the time to document your code at the moment. | |||
|} | |||
Revision as of 00:28, 25 May 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 / /!; format /** * / is 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