Conventions

Code formatting

To prevent git conflicts and ugly histories, please always format your code with the eclipse formatter ctrl+shift+f. Unfortunately, unlike for Java projects, eclipse does not provide an automatic formatting at saving a file. Therefore please try to get used to always press a combination of ctrl+s and ctrl+shift+f! Additionally make sure to configure your formatter to use a line length of 140 characters instead of the default 80. To do so go to Preferences -> C/C++ -> Code Style -> Formatter and then edit your profile such that Line Wrapping -> Maximum Line Width = 140

File structure

The L1 and L2 specific algorithms should be implemented within the folders l1 and l2. Code that is shared by L1 and L2 should be stored in common. Within all these three folders code related to one detector should always be stored in a detector specific folder as in l1/straw/ unless the code is supposed to be reused by other detectors.

Code conventions:

Naming conventions

• CamelCase (don't use '_' in Methode/Variable names except in following two points)
• Non-static instance variables are lower case and end with _ e.g. int someVar_;
• Static instance variables are upper case and end with _ e.g. static int SomeVar_;
• Local variables are lower case without a _ e.g. int someVar;
• Global constants are written uppercase with _ between every word like #define SOURCE_ID_L0TP 0x40
• Class names are capitalized as in class SomeClass {
• Method names are in lower case e.g. void doSomething() {

Flow of control conventions

Avoid using

if(condition)
    doSomething();
else
    doSomethingElse();

except for the simplest of cases. Otherwise use

if(condition) {
    doSomething();
}
else {
    doSomethingElse();
}

One should also note that else statements should be on their own line, however else if may occupy a single line. You will likely need to change this preference in your code formatter.

Never use

for(int i=0; i < 10; i++)
    doSomethingWithI(i);

instead of

for(int i=0; i < 10; i++) {
    doSomethingWithI(i);
}

Comments

Code that is commented out should ideally have no space between the slashes and the code. For example:

if(condition) {
    //commentedOutFunction();
    functionWeAreTryingOut();
}

Comments explaining the code should always have a space between the slashes and the actual comment. For example:

if(condition) {
    // This ensures that no more than two hits have been detected
    hitDetectorFunction();
}

C++11

Use c++11 syntax and objects like in following examples:

• Range-based loops:

std::vector<int> v = someFunction();
for (int i: v) {
    std::cout << i << std::endl;
}

• Type inference:

auto myMap = getSomeMap();
for (auto& keyValue : myMap) {
    std::cout << "Key: "<< keyValue.first << ", value: " << keyValue.second << std::endl;
}

• Use move semantics and rvalue references:

void addElement(Element&& e) {
    myVector.push_back(std::move(e));
}

• Use std::unordered_set and std::unordered_map with O(const) access time instead of the binary tree implementations (std::set and std::map) with O(n*log(n)) access time if you have large collections.

• Consider using std::unique_ptr, std::shared_ptr and std::make_shared

• Nested constructors:

class MyClass  {
    int num_;
public:
    MyClass(int theNumber) : num_(theNumber) {}
    MyClass() : MyClass(23) {}
};

• Use nullptr instead of NULL
• Initializer lists: MyStruct vector = {0.23f, 42.5f};
• See more at wiki