Code style

Here lies the information related to the style that governs the coding in phyx. These aren't hard and fast rules, but general guidelines that are meant to keep the style of each file somewhat consistent to make the barrier of entry for any other coders a little easier. Of course, every coder has preferences (tabs, spaces, placement of brackets, names of functions), but fight the urge to change the style.

General note on classes

phyx is coded in C++ to take advantage of some of the standard library and some additional tools that are available in C++. In general though, it would be good to keep the structure of these simple (e.g., not a ton of virtual calls, deep inheritance, etc.). The classes that are created should also be made simple with the goal of a simple architecture. It will be necessary and beneficial to have classes, especially for common data types and calculators.

Files

In general, the functions and descriptions should be written in .cpp files. For every .cpp file (except main_*.cpp files) there should be a header .h file.

Names

Namespaces

Although originally used, the following:

using namespace std;

is no longer permitted. Instead, use explicit namespace qualifications, e.g.:

std::vector<std::string> vec;

If necessary, can use a using declaration, e.g.:

using std::cout;
using std::endl;
...
cout << "I don't like typing extra characters." << endl;

This allows quicker implementation. But ideally after successful testing that a method works these will converted to use the explicit namespace qualifications above.

Variable names

Variable names should be lower case with underscores separating words (e.g., num_taxa). Member variables should have a trailing underscore (e.g., num_taxa_).

Class names (type names)

Class names should by mixed case (MyClassName)

Function names

Function names should be lower case with underscores separating words.

Errors

Print error messages to std::cerr, not std::cout.

Comments

Useful comments (that don't repeat what is obvious from the code) are essential to make the code accessible to new coders. Short one liners should be with the standard // with longer comments within multi-line /**/

Files comments

There should be a comment at the beginning of each file with the license and a description of the purpose of the code in the file.

Function and class comments

There should be comments before each function or class that describes the specific purpose of this code and the intended use. When the function is doing something that would be considered analysis, it would be helpful to record the citation that describes the method.

TODO

When there are elements of the code that need to be looked over or functionality that needs to be added, make note of this with a TODO comment. So basically, add the word TODO to the beginning of a // or /**/ comment.

Formatting

The formatting of the code is intended to have consistency and readability.

Spaces

phyx uses spaces instead of tabs, and a tab should be 4 spaces.

Curly braces

Always use curly braces, even when there is a one-liner conditional. Also, opening curly braces { shouldn't be to be on a line of their own.

Other formatting

Unless it starts to get out of hand, for now, there don't need to be any other statements about style. However, if something comes up, it will be added here, so check back.