Coding Guidelines for Level 3 Tools

Please try to stick to the D0 coding guidelines, and in addition to those use the following, meant to avoid waste of cpu time.

Use of ctest

All level 3 code will use ctest to interface to SRT (the probable move from ctest to ctbuild should be fairly easy). This is non-negotiable. In addition, the component and integrated tests should be performed (i.e. no dummy tests, except for abstract classes).

Directory Structure

Each level 3 package will have (at least) the following directories:

package_name/package_name contains the include files (.hpp & .icc)
package_name/src contains the source code (.cpp) and component tests (_t.cpp)
package_name/test contains the integrated test scripts

General Language Considerations

Aside from standard issues like multiple embedded loops which are fairly obvious and can often be circumvented, some commonly used features of c++ are known major cpu consumers.
Dynamic memory allocation is the prime example, so please minimize the number of new and delete instructions in the event processing (DoThisTool method and methods called - directly or indirectly - in DoThisTool). Instead, reserve this memory at start of run (by using the new in the MakeMe method), and reuse it for each event. The delete instruction then belongs in the destructor.
Note: a (dangerous) consequence of this is that if these objects are inserted in a container and
the container is deleted they may be unexpectely deleted too. I therefore recommend to be very careful when using containers outside of the MakeMe method.
If you're using l3vectors (see below), please create them with sufficient space at start of run and avoid increasing their size often.

Please avoid global using directives, i.e. don't use statements like "using namespace std;", or "using std::string;" in header files, unless it's inside a class or structure declaration.

Use of string and containers

The standard library containers (and string) make extensive use of dynamic memory
allocation (through the use of new, delete or equivalent instructions). This can be very
cpu intensive, so we ask that you use the following instead:

l3string
l3vector
l3map

They can be used just like std::string, std::vector and std::map but we plan to implement
them in a different way. Any class that inherits from bTool will know about these (they
are defined in "l3ftoolbase/l3types.hpp").
The use of any other container, and in particular std::list, is deprecated. Should you
wish to use any of these, please discuss it with Amber and Gustaaf first.

Recommendations from benchmark tests (provided by Charles Leggett):

Use switch - case, rather than if - else
Use iostream.getline instead of iostream >> for character I/O
Minimize the number of parameters passed to functions
Minimize the levels of abstraction ( = Minimize the levels of hierarchy)
Use while loops rather than for loops where possible
Do boolean operations on bit/bytes in loops rather than bit/byte arrays
Use inline extensively (in accordance with the D0 guidelines: don't put code in the class declaration, but a lot of inline function(..){...} below the class declaration). However, do not inline code that has an exception throw.
Avoid comparing strings.

And finally

If you have any questions, feel free to contact Amber or Gustaaf.

GB/Dec. 10 1998