TWiki> LHCb Web>LHCbComputing>LHCbCodingGuidelines (revision 5)EditAttachPDF

LHCb Coding Guidelines

Table of Contents

Coding Conventions

  • The original (from 2001) C++ coding conventions are described in note LHCb-2001-054
  • An emacs customisation file has been developed by Olivier Callot to produce standard templates for source code files

Data Model 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.
  • All member variables should be initialised in the constructor, even if they are again initialised in the initialize() method. Pointer variables should be initialised to NULL
  • 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 NULL to avoid double deletion:
if( NULL ! = m_thePointer ) {
delete m_thePointer;
m_thePointer = NULL;

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 - 09-Dec-2013

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2013-12-11 - StefanLohn
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback