Coding Convention

If you want to document your message somehow use the following scheme:

• add it to group developers_failures_group if it is a message of a caps_developers_failure_report() call
• add it to group runtime_error_group if it is a message of one of the caps_print_error() call
• add it to group runtime_warning_group…
• add it to group runtime_info_group…

If you have documented your message in such a way, extend the call with the NOTE documented comment, to show, the message should not be changed without changing the documentation as well.

[…]
caps_developers_failure_report("Invalid print progression report!"); // NOTE documented
[…]

This should avoid divergence of the message the user reads and its documentation here. A user should be able to find the exact message in the documentation (modulo the language translation).

Near the function emitting such a message, a Doxygen comment block should follow with the structure shown below:

[…]
@addtogroup <the corresponding message group>
 
  **<the original message in English**@n
  <the description>
[…]

An example:

[…]
@addtogroup developers_failures_group
 
**Invalid print progression report!**@n
In your caps_job_progression structure some members shouldn't have the value
'0' because it makes no sense (there is @b no page 0!).
[…]