-
Notifications
You must be signed in to change notification settings - Fork 0
MOOSE Code Standard
- All header files should have a ".h" extension while all C++ source files should have a ".C" extension.
- Header files always go either into "include" or a sub-directory of "include" while source files go into "src" or a subdirectory of "src".
Header and source file names must match the name of the class that the files define. Hence, each set of .h and .C files should contain code for a single class.
- src/ClassName.C
- include/ClassName.h
-
ClassName
Class names utilize camel case, note the .h and .C filenames must match the class name. -
methodName()
Method and function names utilize camel case with the leading letter lower case. -
_member_variable
Member variables begin with underscore and are all lower case and use underscore between words. -
local_variable
Local variables are lowercase, begin with a letter, and use underscore between words
namespace Moose
{
// no indent!
int // return type should go on separate line
junkFunction()
{
// two spaces!
if (name == "moose")
{
// Spaces on both sides of '&' and '*'
SomeClass & a_ref;
SomeClass * a_pointer;
}
// space around assignment operator
int foo = 5;
}
// Constructor
SomeClass::SomeClass() : // space before colon
// four spaces for initialization list
member_a(2),
member_b(3)
{ // Empty functions should still have curly braces on separate lines
}
} // namespace Moose
When creating a new variable use these patterns:
unsigned int i = 4; // Built-in types
SomeObject junk(17); // Objects
SomeObject * stuff = new SomeObject(18); // Pointers
MOOSE currently does not allow any trailing whitespace or tabs in the repository. If you are using our standard Emacs file this shouldn't be a problem. However, if you still end up with trailing whitespace that needs to be removed before a check-in. Try running the following one-liner from the appropriate directory:
find . -name '*.[Chi]' -or -name '*.py' | xargs perl -pli -e 's/\s+$//'
Firstly, only include things that are absolutely necessary in header files. Please use forward declarations when you can:
// Forward declarations
class Something;
All non-system includes should use quotes. There is a space between include
and the filename.
#include "LocalInclude.h"
#include "libmesh/libmesh_include.h"
#include <system_library>
Try to document as much as possible. We suggest using the Doxymacs plugin to help with documenting. Just put the .el files from the no-autoconf into your load-path and then add the hooks to load doxymacs-mode. I'm just using C-c d f
before a function/class to auto generate a comment template like so:
/**
* The Kernel class is responsible for calculating the residuals for various
* physics.
*
*/
class Kernel
{
public:
/**
* This constructor should be used most often. It initializes all internal
* references needed for residual computation.
*
* @param system The system this variable is in
* @param var_name The variable this Kernel is going to compute a residual for.
*/
Kernel(System * system, std::string var_name);
/**
* This function is used to get stuff based on junk.
*
* @param junk The index of the stuff you want to get
* @return The stuff associated with the junk you passed in
*/
int returnStuff(int junk);
protected:
/// This is the stuff this class holds on to.
std::vector<int> stuff;
};
Where possible, follow the above rules for Python. The only modification is to the naming of member variables in classes. This should be done as follows:
class MyClass:
def __init__(self):
self.public_member
self._protected_member
self.__private_member
- Thou shall prefer references instead of pointers whenever possible (i.e. this object lives for a shorter period of time than the object it needs to refer to does)
- Methods shall return pointers to objects if said objects are stored as pointers and references if said objects are stored as references
- When creating a new class:
- Include dependent header files in the *.C file whenever possible (i.e. the header uses only references or pointers in it's various declarations) and use forward declarations in the header file as needed
- EXCEPT when doing so would require end users to include multiple files to complete definitions of child objects (Errors typically show up as "incomplete class" or something similar during compilation)
- When hacking - always have tickets entered first (Ticket First Hacking)
- Avoid using a global variable when possible.
- Every destructor thou makes shalt be virtual.
- All function definitions should be in *.C files! The only exceptions are for inlining speed and templates.