It is always good practice for programmers to adopt some sort of style convention when developing new code. This helps keeping the code readable for both authors and collaborators, as well as for people that read your code on online repositories. Here I will set a precedent for a minimal C++ code style for Reed’s group encompassing C++ features we normally use based on the most common practices out there, so that we can more easily help each other with out codes and keep consistency when publishing them. This post may be updated if somebody sets precedents for C++ features didn’t account for (e.g. namespaces).

Naming conventions

Classes : Uppercase first letter. If the class name is comprised of more than one word, all words should be written together (no dashes, underscores, etc.) and the first letter of each word should be capitalized. E.g.: MyAwesomeClass .

: Uppercase first letter. If the class name is comprised of more than one word, all words should be written together (no dashes, underscores, etc.) and the first letter of each word should be capitalized. E.g.: . Functions : Lowercase first letter. If the function name is comprised of more than one word, all words should be written together (no dashes, underscores, etc.) and the first letter of each word except the first should be capitalized. E.g.: myGreatFunction . If you are creating a getter or a setter, be sure to follow the this standard. E.g. the getter for variable “ t his_variable” would be “ get T hisVariable .”

: Lowercase first letter. If the function name is comprised of more than one word, all words should be written together (no dashes, underscores, etc.) and the first letter of each word except the first should be capitalized. E.g.: . If you are creating a getter or a setter, be sure to follow the this standard. E.g. the getter for variable “ his_variable” would be “ .” Variables : All in small letters with words separated by “_” (underscore). E.g. this_variable.

: All in small letters with words separated by “_” (underscore). E.g. this_variable. Constants: All letters capitalized and words separated by underscores. E.g. MY_GREAT_CONSTANT.

Other naming rules

Besides naming conventions, there are other good practices when it comes to coming up with names in your code:

Do not assign one letter names , unless it is a temporary variable such as i, j, k used as indexes.

, unless it is a temporary variable such as i, j, k used as indexes. Assign informative names to your classes, functions, variables and constants. If you have a variable called “length,” another called “thisLength” and a third one called “realLength” your code will be really hard to follow.

to your classes, functions, variables and constants. If you have a variable called “length,” another called “thisLength” and a third one called “realLength” your code will be really hard to follow. Being concise is great (nobody reads code for its poetic variable names) but avoid shortening your names too much . Calling a variable “catchmentFallCreekIthaca” makes it much easier for someone else to know the information contained in that variable than calling it “catfacreith.”

. Calling a variable “catchmentFallCreekIthaca” makes it much easier for someone else to know the information contained in that variable than calling it “catfacreith.” We all get really frustrated with our codes at times, and want to curse it really bad. It’s fine to do it in your office when nobody is hearing, but be sure to not let that leak into your code and to keep some decency: e.g. avoid having in your code “this&%$*%DoesNot&$%*#@Work = true” or anything of the sort.

Other rules

Avoid magic numbers (hard coded numbers). Codes like the one below not only are hard to understand but also make the reader question if the results of the code are actually right: if (312 * evaporation + inflow / 52 - 7 * demand) { // Do something here } Now imagine if the value 212 is the value of an area and is used in 83 different parts of your code: that’s a problem. Instead, declaring those numbers as constants would be preferred: const double DRYVILLE_RESERVOIR_AREA = 312.0; const double NUMBER_OF_WEEKS_IN_YEAR = 52.14; const double NUMBER_OF_DAYS_IN_WEEK = 7.0; // Lots of code here, since constants are normally declared at the top of the code. if (DRYVILLE_RESERVOIR_AREA * evaporation + inflow / NUMBER_OF_WEEKS_IN_YEAR - NUMBER_OF_DAYS_IN_WEEK * demand) { // Do something here }

Keep your cpp files shorter than 500 lines . If you start approaching 500 lines, it may be the case that your class can be broken into parent and multiple children classes, or into two completely different classes.

. If you start approaching 500 lines, it may be the case that your class can be broken into parent and multiple children classes, or into two completely different classes. Have only the main.cpp file in the root directory . All other files, if any, should be in directories so that the code is easy to navigate through.

. All other files, if any, should be in directories so that the code is easy to navigate through. If there is an issue or simplification to be fixed at some point in the future, use the “//FIXME:” comment to indicate it, as in the code below: //FIXME: replace constant area below by storage vs. area curve. if (DRYVILLE_RESERVOIR_AREA * evaporation + inflow / NUMBER_OF_WEEKS_IN_YEAR - NUMBER_OF_DAYS_IN_WEEK * demand) { // Do something here }

Note that different languages have different standards. If coding in Python or Matlab, for example, be sure to follow the best practices for these languages. Also, if developing code in collaboration with another research group, be sure to negotiate a convention.