Coding standards

Owned by Josh Siegle
Last updated: Mar 22, 2016 by Aaron Cuevas
2 min read

Formatting rules

To keep the source code looking clean and consistent, we're using the Artistic Style command-line processor. This program will automatically enforce formatting standards whenever it's run. If you're doing a lot of development you should run this periodically to keep your code congruent with the rest of the source.

This will parse the astyle.options file and apply the appropriate formatting changes to the source code. These include:

  • ensuring each bracket is on its own line
  • converting tabs into 4 spaces
  • properly indenting sections of code
  • removing spaces around parentheses
  • inserting a space after "if," "while," or "for"
  • moving pointer/reference operators to the left, next to the type

All of these formatting options are good to keep in mind while you're writing code. But if you forget to implement them, astyle will take care of it.

Linux

Install astyle (sudo apt-get install astyle). Then enter the following from the top-level directory for the GUI:

astyle --options=astyle.options --recursive "./Source/*.cpp" "./Source/*.h"

Windows

An AStyle extension can be installed in the Professional editions of Visual Studio (2010 and higher).

To set up the extension, open Tools -> Options -> AStyle Formatter, and import the astyle_VS.cfg file in the top-level directory for the GUI.

To run the formatter, choose Edit -> Advanced -> Format Document/Format Selection.

General coding style

When it comes to more subjective stylistic considerations, feel free to comment on anything we're doing that's not optimal. Since most of the GUI's developers don't have any formal training in C++, we had to make up a lot of things as we went along. Here are some general rules we try to adhere to:

  • Any classes that are responsible for creating and destroying other classes should use JUCE's ScopedPointers or OwnedArrays to ensure that everything is cleaned up automatically. Classes that merely need to interact with other classes can use standard C++ pointers.
  • Method definitions, including empty methods, must not be present on header files on any class defined as PLUGIN_API. All the code for those methods must be placed in their respective .cpp files.
  • We haven't used exceptions anywhere in the code.
  • Class names should begin with a capital letter, object names should begin with a lowercase letter.
  • Names of all classes, objects, methods, and members should be in camelCase (no underscores, please...save it for Matlab).
  • However, names of constants should be written in ALL_CAPS, in which underscores are appropriate.
  • Names should be as descriptive as possible without being verbose (obviously there's no definitive rule for this).

If you have any suggestions about how to improve our coding style, we'd definitely like to hear them. Much of what constitutes our "style" was picked up from the JUCE example code. So when in doubt, you should default to the standards set for the JUCE Library.

Conventions related to functionality

  • All channel numbering schemes must start at zero if they're handled by the computer, and one if they're visible to the user.