This section specifies the code standards for the development of new functionalities in the dnn_opt library.
1.1. Use lower snake case all the time, even for class names (C++ Standard Library convention).
1.2. Variable names and identifiers should be written in English. Avoid the use of contractions.
1.3. Private and protected members should start with m_.
1.4. Each line should contain no more than 80 characters.
1.5. Use two space indentation, never use tabs.
1.6. Do not indent private, protected, public keywords. Do not indent nested namespaces or classes within.
1.7. For initialization in the constructors, start the initialization list in a new line, including the two dots (:). Prefer one line for each initialized member if you need more than one line.
2.1. Put braces in its own lines.
2.2. Close each namespace with a comment indication: // namespace namespace_name
2.3. Code segments that are designed for local usage should be placed within a void namespace.
2.4. Declare variables at the beginning of its code block, leave an empty line after.
2.5. Separate logical code blocks by empty lines if you feel this will improve readability.
2.6. Leave an empty line before the closing brace of a class and before the return statement of a method implementation.
3.1. Prefer using the enclosed form of comment for documentation /* this is a comment*/ instead of other forms.
3.2. If you need to put some explanatory comment put it in the line above. Leave an empty line if the comment apply for more than one line below. Use this together with 2.5.
3.3. Document all classes and function you write, use the Java @command form instead of the \command.
3.4. For each class you should specify a @brief, @author, @version and @date. You can optionally put some extended description after the brief in several new paragraphs.
3.5. For each function you should specify a @brief, @param, @throws, @return. You can optionally put some extended description after the brief in several new paragraphs.
3.6. For each member attribute you should declare its purpose above.
3.7. Begin each header file with a copyright disclaimer as a comment.
3.8. Make your best to include ISO 690 references for established algorithms in the extended description of the documentation when applicable.
4.1. Prefer putting the pointer modifier * next to the type declaration.
4.2. Avoid the use of the auto keyword.
4.3. Use a space to separate operators and operands. Do not use space to separate parenthesis.
4.4. Always specify virtual modifier in derived classes.
4.5. Include headers that do not belong to the library first using <> for non local files and then include the headers that belong to the library using "" for local files.
4.6. In .cpp files implement the most important methods of the class first, then implement trivial methods (e.g. getters and setters) and finally implement the constructor and destructor of the class.
4.7. Use nullptr instead of 0 to indicate a null pointer.
4.8. Never use using namespace in a header file. This causes the namespace you are using to be pulled into the namespace of all files that include the header file.
4.9. Use include guards in header files.