Skip to content
Andreas Neiser edited this page Jul 10, 2017 · 5 revisions

Here are some points that should be followed if possible when contributing to Ant. Read the existing source and try to infer the spirit of this project. Have a look at software development books, such as "Effective Modern C++" by Scott Meyers and "Clean Code" by Robert Martin.

General remarks

  • In any case, use Github, open issues, provide pull requests, make your wishes, thoughts, code changes public as early as possible. Don't promise to publish something some day later, and then never do it.
  • Prefer general solutions and avoid hardcoding things, such as number of channels of detectors, they might change and novices don't know that 720 or 672 might have something to do with the CB.
  • If you're aware that you're doing something "not quite right", label it with /// \bug ... doxygen-aware comment blocks and describe the problem.

Const Correctness

See C++ FAQ.

Use RAII and exceptions

Do not manually handle error conditions, but throw things derived from std::exception. RAII makes your code naturally exception-safe with respect to memory leaks.

The standard library is your friend

  • Do not use char*. use std::string
  • Do not use C-style arrays, use std::vector
  • Do not use printf, use the std::ostream& operator<< technique

Don't be afraid of new data types

C++ has zero-overhead for data types if done right. But usually, even performance drawbacks are acceptable if the solution looks easier to understand and/or is more general.

Avoid raw pointers

But use std::unique_ptr and std::shared_ptr, although ROOT makes this hard as it has its own weird understanding of object ownership. There are wrappers in Ant, such as src/base/WrapTFile.h and src/base/WrapTTree.h.