Coding Standards

Layout and Whitespace

• Always put a space before and after all arithmetic binary operators!
• The ! operator should always be followed by a space.
• The ~ operator should be preceded by a space, but not followed by one.
• The ++ and -- operators should have no spaces between the operator and its operand.
• Never put a space before a comma. Always put a space after a comma.
• Always put a space before an open parenthesis! (One exception to this is if you've got a pair of empty parentheses)
• Don't put spaces after a parenthesis. So a typical method call might look like this: foobar (1, 2, 3);
• In general, leave a blank line before an 'if' statement.
• In general, leave a blank line after a closing brace '}'.

####Examples int xyz = foo + bar // I like this because it's clear at a glance + func (123) // that these lines must be continuations of - def + 4321; // the preceding ones.

int xyz = foo + bar +      // Not so good.. It takes more effort here
      func (123) -     // to see that "func" here does not begin 
      def + 4321;      // a new statement.

// Good:
AffineTransform t = AffineTransform::translation (x, y)
                                .scaled (2.0f)
                                .rotated (0.5f);

// Bad:
AffineTransform t = AffineTransform::translation (x, y).
    scaled (2.0f).
    rotated (0.5f);

Naming conventions

• Member variables and method names are written with camel-case, and never begin with a capital letter
• Class names are to be written in Pascal case
• Avoid underscores in names, especially leading or trailing underscores.
• Macros should be ALL_CAPS_WITH_UNDERSCORES
• Enums should conform to the same naming standards of classes and their members

##Memory Managment

• Absolutely do NOT use 'delete', 'deleteAndZero', etc. There are very very few situations where you can't use a ScopedPointer or some other automatic lifetime management class.
• Do not use 'new' unless there's no alternative. Whenever you type 'new', always treat it as a failure to find a better solution. If a local variable can be allocated on the stack rather than the heap, then always do so.
• Never use 'new' or malloc to allocate a C++ array. Always use a HeapBlock instead.
• ..and just to make it doubly clear: You should almost never need to use malloc or calloc at all!
• If a parent object needs to create and own some kind of child object, always use composition as your first choice. If that's not possible (e.g. if the child needs a pointer to the parent for its constructor), then use a ScopedPointer.
• Whenever possible, pass an object as a reference rather than a pointer. If possible, make it a const reference.
• Obviously avoid static and global values. Sometimes there's no alternative, but if there is an alternative, then use it, no matter how much effort it involves.
• If allocating a local POD structure (e.g. an operating-system structure in native code), and you need to initialise it with zeros, use the "= { 0 };" syntax as your first choice for doing this. If for some reason that's not appropriate, use the zerostruct() function, or in case that isn't suitable, use zeromem(). Don't use memset().
• Treat Component::deleteAllChildren as a last resort - never use it if there's a cost-free alternative.
• The juce::ScopedPointer class is written to be compatible with pre-C++11 compilers, so although it does offer C++11 move functionality for supported compilers, it's not as versatile as std::unique_ptr. So if you can use std::unique_ptr in your own code, that's probably a better bet.

This coding standard is based on juce's coding standards defined here