Ardour Code Style

This isn’t meant to be a strict listing of how your code must be. It is intended to help your code fit in with the rest of the Ardour codebase. This is the style that we have evolved to.

1. Use tabs, not spaces for C++ code. Many of us use different indentation levels and this lets us view it as we like.
2. That said, in Python files, use spaces, not tabs. Tabs seem to get a little messed up and spaces are more rigorous where it is important.
3. Always use curly braces with if-, for-, do-, and while-statements.
4. Since this is C++, use 0, not NULL.
5. Similarly, use true/false, not TRUE/FALSE
6. If an argument is being passed by reference, and cannot be null, always pass it as a reference, not a pointer.
7. Prefer references over pointers
8. For core (libardour) data structures, prefer shared_ptr to manage lifetimes
9. Never, ever bind a shared_ptr to a sigc::signal. Always convert to a weak_ptr first.
10. In GNU Emacs, use the “linux” C and C++ mode style
11. When incrementing any STL iterator, always use ++iter, not iter++
12. When looping over any STL container and performing operations on its contents or iterators to it, always consider the possibility that the operation may remove items from the container and thus invalidate the iterator you are currently operating on. The typical approach looks like this:
    

       for (iter = container.begin(); iter != container.end(); ) {
           Iterator tmp;
             
           tmp = iter;
           ++tmp;
     
            .... do something ...
    
           iter = tmp;
    
       }
    

13. Because of the previous issue, generally prefer std::list over std::vector. Erasing an element within a vector invalidates iterators to all later elements. Use vector only when confident that this issue doesn’t exist.
14. Class types have names like SomeClassType; variables have names like a_pleasant_name.
15. Use const wherever possible.
16. Throw PBD::failed_constructor to exit constructors abnormally, and catch this exception.
17. That said, attempt to perform object initialization in an init function that is called post-construction. See Meyers for more information on this pattern.
18. Use cstdio, not stdio.h style standard includes.
19. Never declare using namespace in a header.
20. Don’t even think of using Microsoft-style “Hungarian” notation
21. When constructing paths (“filenames”) do not include separators (“/”) and try to use Glib::build_filename()
22. Use Glib for any file-system related activities (creating/removing/testing for files)