LHCb Coding Guidelines

Table of Contents

C++ Coding Guidelines

  • We suggest to follow, as much as possible, Bjarne Stroustrup's C++ code guidelines. Note that C++14 is allowed as from the LHCb v41r* software stack. It is not allowed in the LHCb v40r* stack (2016-patches branch in Gitlab) and earlier to preserve compatibility with gcc48.
  • All code must compiled without warnings with all compilers for which we run nightly tests. Currently (March 2018) these are gcc62, gcc7.3, clang50. See https://lhcb-nightlies.cern.ch/nightly/. Check also for warnings in the Coverity code analyser
  • For a historical perspective, the original (from 2001) LHCb C++ coding conventions are described in note LHCb-2001-054. Many of the recommendations are still valid, as well as the naming conventions.
  • An emacs customisation file was developed to produce standard templates for source code files

Units Conventions

LHCb applications conventions

  • Rules for return status codes for algorithms and tools running in production applications
  • Rules for printout from algorithms and tools running in production applications. See also the printing from Gaudi FAQ
  • The Gaudi base classes for algorithms and tools provide implementations for the initialize() and finalize() methods. If you don't need to do anything specific in these methods, you not should not override the base class implementations in your derived class - rely on polymorphism to do its job.
  • new in initialize() must be matched by delete in finalize(), not in the destructor. If the pointer to be deleted is a member variable, test equality to nullptr to avoid double deletion:
if( nullptr ! = m_thePointer ) {
delete m_thePointer;
m_thePointer = nullptr;
}

Interaction with the Transient Event Store

  • Algorithms must always create their output containers, even if empty.
  • Algorithms and Tools should test for the existence of a TES container before accessing it. Use the getIfExists function rather than an if( exist() ) get() construct.
    • Alternatively, if absence of the input container should never happen in the application, use the get function. This will throw an exception if the container is missing, and stop the event processing.

Monitoring and Checking

Monitors are algorithms that monitor the performance of the code using real data only (no MC truth)

Checkers are algorithms that check the performance of the code by comparing to MC truth information, and therefore cannot run on real data.

Any monitoring or checking algorithms that produce histograms must inherit from the GaudiHistoAlg base class. This provides many shortcuts for booking and filling histograms, and also enforces the convention that the histograms should be stored in directories that have the name of the algorithm producing them. The HistoTopDir should be set to the sub-detector name. Within an algorithm, histogram identifiers can be freely chosen by the developer; any alphanumeric string is allowed.

Algorithms producing NTuples should inherit from the GaudiTupleAlg base class, which itself inherits from GaudiHistoAlg. Use such algorithms with care: NTuples grow with the number of events, they should be used only in end-user analysis, not in production applications.

See also the Gaudi histogramming FAQ

Performance tips and tricks

Very old links

-- MarcoCattaneo - 22-Jul-2016

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r8 - 2018-03-28 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback