Coding Guidelines

When you're writing code for open source projects, the most important rule to follow is this: Try to make your code blend in with the existing code.

That being said, there are large chunks of Mixxx that are written in slightly differing styles (mainly variable naming conventions). In order to avoid this in the future, it's best for us to have some coding guidelines for developers to follow.

• Class names follow the “MyName” format, with each word capitalized.
• Member functions follow the usual “thisFunction” naming convention.
• Private variables throughout the class should ideally start with “m_”, and although this hasn't been followed thus far, it's a good idea to use it because it tells you the scope of a variable without having to dig through a header file.

Mixxx's old developers more or less used the convention that indents are 4 spaces. The consensus is that we should try to stick to this, if only for consistency.

Please bear this in mind when writing code.

The mixing engine code inside Mixxx needs to run in realtime and must execute as quickly as possible in order to minimize the chance of buffer underruns in the soundcard.

Here's some coding tips to help keep performance decent:

• Don't use signals/slots in code that gets called in the callback thread - that is, use signals/slots to interact with any EngineObject's process() function.
• Don't access ConfigKeys in code that gets called in the callback thread (same as above). ConfigKey access is slow - Use a ControlObject instead. In some situations, you may have to have both a ConfigKey (to save a setting) and a ControlObject to access it (to read the setting, in high performance code).