Here is a list of coding rules that are enforced by the plumedcheck script. These rules are necessary to be sure that the codebase is consistent. Code not satisfying these rules will make the automatic test on travis-ci fail. In the following we provide a list of errors that are detected automatically, together with a short explanation of the reason we consider these as errors. The names used are the same ones reported by plumedcheck. The plumedcheck script can be used as is, but the simplest way to obtain a report is to go to the buildroot/src directory and type make plumedcheck. In case you think you have a valid reason for a code not passing the check to be merged, please contact the developers.

wrong_module_type

Module type as indicated in the module.type file located in the module directory is not valid. The admitted types are: default-on, which means the module is on by default, default-off, which means that they should be explicitly enabled, and always, which means they are always required.

astyle

In order to keep the code readable, we use the astyle program to format all source files. This error indicates that the reported file has not been formatted correctly. It is important that the version of astyle and the options exactly match the ones we use for testing. To this aim, you should use a command such as make astyle from the plumed root directory.

autoconf

In our git repository we distribute both ./configure and ./configure.ac files. When you modify the latter, the former should be regenerated using autoconf and committed to git. This error indicates that the ./configure.ac and ./configure files in the repository are not consistent. Notice that Ubuntu 16 ships with an autoconf version that is not standard (2.69 + some patch). This makes this test report a false positive. This is thus changed to a style warning.

include_dots

It is considered an error to include a file using a path starting with ... The reason is that this would allow to include PLUMED modules that have not been explicitly declared in the Makefile (e.g. using #include "../tools/Vector.h"). This might result in undetected dependences between the modules, which means that by enabling some set of modules one would result in a non-linkable library.

deprecated_headers

There is a list of headers that have been deprecated in C++ and should not be included. These headers should be replaced with their equivalent from the stdlib. E.g., use #include <cstdlib> instead of #include <stdlib.h>. Notice that using the modern header all the functions are declared inside the std namespace.

unsupported_header_regex

Header <regex>, although part of the C++11 standard, is not supported by gcc 4.8. In order to allow compatibility with old compilers, this header should not be used.

external_header (style)

Header files should possibly not include other header files from external libraries. Indeed, once PLUMED is installed, if paths are not set correctly the include files of the other libraries might not be reachable anymore. This is only a stylistic warning now. Notice that with the current implementation of class Communicator it is necessary to include mpi.h in a header file.

non_h_header

Files with .inc extension are generated by PLUMED while it is compiled and are not installed. They should not be directly included in header files, otherwise those header files could be not usable once PLUMED is installed.

multi_registered_action

Each action should be registered (with PLUMED_REGISTER_ACTION) once and only once.

multi_registered_cltool

Each cltool should be registered (with PLUMED_REGISTER_CLTOOL) once and only once.

multi_registered_vessel

Each vessel should be registered (with PLUMED_REGISTER_VESSEL) once and only once.

multi_registered_metric

Each metric should be registered (with PLUMED_REGISTER_METRIC) once and only once.

multi_doc

An action or cltool should be documented once and only once. Notice that because of the way the manual is generated, a cltool cannot have the same name of an action.

using_namespace_in_header

A statement using namespace in header files is considered bad practice. Indeed, this would imply that any other file including that header file would be using the same namespace. This is true also for std namespace, and that's why you typically find full specifications such as std::string in header files. In source files you are free to use using namespace PLMD and/or using namespace std if you like, since these commands will only affect the source file where they are used.

used_has_in_header (style)

Using __PLUMED_HAS_SOMETHING macros in headers should be avoided since it could make it difficult to make sure the same macros are correctly defined when using PLUMED as a library. This is only a stylistic warning now. Notice that with the current implementation of class Communicator it is necessary to include mpi.h in a header file and thus to use __PLUMED_HAS_MPI.

missing_namespace_plmd

Every source file should contain a PLMD namespace. Notice that files in the "outer modules" wrapper and main, that is those that are not included in the kernel library, are exempted from this rule.

missing_namespace_module

Every source file should contain a sub namespace with the same name of the module itself. Notice that there are important exceptions to this rule:

"outer modules" wrapper and main, that are not included in the kernel library.
"core modules" that are part of the core of PLUMED. Since the classes implemented here are widely used within PLUMED, they are directly defined in the PLMD namespace.

missing_guard

Every header file should contain a proper guard to avoid double inclusion. The format of the guard is fixed and should be __PLUMED_modulename_filename_h, where modulename is the name of the module and filename is the name of the file, without suffix. This choice makes guards unique within the whole codebase.

non_existing_cpp

For every header file there should exist a corresponding source file with the same name. Notice that dummy headers that only include another header or which only define preprocessor macros are exempted from this rule.

non_included_h

The source file corresponding to a header file (that is: with the same name) should include it as the first included file. This is to make sure that all the header files that we install can be individually included and compiled.

undocumented_action

Every action that is registered with PLUMED_REGISTER_ACTION should also be documented in a PLUMEDOC page.

action_without_examples

Every action that is registered should contain an Example section in its documentation. Notice that if the Example section is not added the manual will not show the registered keywords.

action_without_verbatim

Every action that is registered should contain an example in the form of a plumedfile section. This is currently a stylistic warning since there are many actions not satisfying this requirement.

unregistered_action

Every action that is documented should be also registered using PLUMED_REGISTER_ACTION.

undocumented_cltool

Every cltool that is registered with PLUMED_REGISTER_CLTOOL should also be documented in a PLUMEDOC page.

cltool_without_examples

Every cltool that is registered should contain an Example section in its documentation. Notice that if the Example section is not added the manual will not show the registered options.

cltool_without_verbatim

Every cltool that is registered should contain an example in the form of a verbatim section.

unregistered_cltool

Every cltool that is documented should be also registered using PLUMED_REGISTER_CLTOOL.

undefined_has

Every macro in the form __PLUMED_HAS_SOMETHING that is used in the code should be defined in configure.ac. This check is made to avoid errors with mis-typed macros.

unused_has

Every macro in the form __PLUMED_HAS_SOMETHING that is defined in configure.ac should be used at least once in the code. This check is made to avoid errors with mis-typed macros.