I would also recommend the online paper C++ Coding Guidelines by David Abrahams and Nathan Myers. This document follows a similar format and I will only attempt to document where our guidelines differ or are more refined.

To understand the importance that naming plays in generic programming, I'd recommend working through Notes on Programming by Alex Stepanov. In fact, before writing any code I'd recommend working through this document.

The style of ASL is a refinement of the style used in the standard library as well as in the Boost libraries. A good general rule is to defer to the highest authority.

ASL is, primarily, a research project even though we strive to make each piece of commercial quality (after all, it is research into how to write large scale systems correctly!). In order to be able to push ASL forward, it is important that each piece is written as correctly as we can. To that end, if there are improvements we can make to the style and interfaces we will, even if that breaks backward compatibility. The challenge of versioning the interfaces in a library such as ASL is an area of research I hope to tackle at some point but for now the burden of maintaining backward compatibility is too high.

Files and the Preprocessor

License

Every file must include the following license as the first item in the file:

File Naming and Structure

Source file names are all lower_case. C++ headers have a .hpp suffix. C++ source files have a .cpp suffix. The include files for ASL are all within the adobe directory and are included using the system include quotes, <...>.

Example:

#include <adobe/algorithm/reverse.hpp>

Where possible - organize the files to match the organization used in STL and Boost. For example, algorithms can be found in adobe/algorithm.hpp. Break up files to a fine granularity to reduce the amount of information which must be included to be compiled. Organize the small headers in a directory with the same root as the master header - adobe/algorithm.hpp will include adobe/algorithm/reverse.hpp.

To further reduce the amount of code included, where possible include a header which only contains forward, or minimal declaration. Such header files should be suffixed with _fwd and only include by other header files. For example adobe/name_fwd.hpp.

Include Guards

All header files should have internal include guards after the license. The include guards are named the same as the file, including the file path, with punctuation replaced by the underscore character.