...

Code indentation and formatting was completely standardized prior to open sourcing the Apache Traffic Server code. Command line tool indent did most of the heavy lifting. This document will describe the indentation, formatting, doxygen comments, class naming, and naming conventions to use.

ATS v2.2 Prefix and Directory Structure changes

In the v2.2 release of Apache Traffic Server, we made some changes to prefixes, and directory structure. Some of this work is still undergoing, see this page for additional details. The most important part of these changes is the semantics of the prefix name spaces:

Public APIs (ts/ts.h, ts/experimental.h etc.)

The prefix to use for these include files and underlying code in e.g. InkAPI.cc is one of

• TS or TS_
• ts

In addition, none of these methods, struct names or definitions should be used in the core itself, other than the actual API implementations (InkAPI.cc etc.).public (API) headers 

Internal code

For all other code that's internal, the prefix should be one of

...

No new code / functionality should be added using the ink/INK prefix. Long term, we will migrate these into the ats/ATS prefix. Adhering to these rules is important, the goal is to be able to easily distinguish public from private APIs. In the past, we've had several cases where public APIs were used in the private code implementation, and this is a bad idea for both performance and functionality.

Header files

In most subsystems, header files are named with a P_ or I_ prefix. P_ files should contain any types and definitions that are private to the subsystem, while the public interface should be contained in a I_-prefixed header.

...

The easiest way to format the code is to simply run 

$ make clang-format

...

No more than 1 adjacent empty line (clang-format enforces this). Leave a blank line after the closing branch when you have the same indentation level (clang-format sometimes messes this up).

You should have this :

void
foo(...)
{
  if (...) {
  }
 
  if (...) {
  }
}
 
void
bar(...)
{
  ...
}

clang-format binary and configuration

You must use the same clang-format binary as everyone else is. This is unfortunate, but is a side effect of how the clang-format team manages their code. You can download the current version, from April 13th 2018. Alternatively, you can build your own version from the clang / llvm source tree, but the tar-ball above includes binaries for both Linux and OS X. You have to copy either of these into somewhere your $PATH will locate, and rename it to just clang format. E.g.

$ tar xf clang-format-20180413.tar.bz2
$ sudo mv clang-format/clang-format.linux /usr/local/bin/clang-format

...

In addition to the binaries, there is a git script as well as en Emacs mode for clang-format.

...

• Upper case for the first character of the name
• Use camel case (GoodClassName)

Methods

• Use camel STL style underscored lower case names for method names with the first charter being lower case (goodMethodName), (e.g. find_if).
• Predicates should use a prefix of "is_" or "has_" to check for a specific propery (e.g. is_valid).
• Use "this→" when calling other methods in the same class, to distinguish from free functions.Prepend '_' to the beginning of private or protected methods

Member Variables

• Prepend '_' to the beginning of the private or protected member variable to distinguish it from other variable

...