Coding Conventions
From Yage3D Wiki
This document outlines best practices for keeping the Yage source code clean, organized, and consistent with itself.
Contents |
[edit] Formatting
Class and struct names should be ProperCase; Functions should appear as camelCase(); Instance and primitive names are lowercase, with optional underscore word separators.
Classes should start with public and private fields, then constructors/destructors, followed by public methods and then private methods, then static methods. Methods that share documentation comments may be grouped. Other methods may also be grouped but should generally be alphebetized.
When in doubt, look for other code with similar functionality. When still in doubt, rely on http://www.digitalmars.com/d/dstyle.html.
[edit] Logging
Any attempt to load a resource from the file system should be logged, as should engine initialization and shutdown. Nothing that would normally end up inside a rendering loop should be logged. In the log output, any filenames should be surrounded with single quotes.
[edit] Error Handling
Functions should use contracts to enforce preconditions when possible, and throw exceptions when they fail. Exceptions should include error messages. Remember that contracts are for the programmer and not the end user; they disappear when compiled in release mode.
[edit] Consistency
Consistency should be checked in the following areas:
- Classes should override the .toString() method (when reasonable) to print out useful information for debugging.
- All relevant Nodes should have a constructor, copy constructor, and destructor or equivalent remove method.
- All Nodes that use resources should have set[Resource](ResourceType) and set[Resource](filename) methods.
- Formatting of messages written to the logs and also messages thrown with exceptions.
