Best practices for code development

Use known C++ best practices when writing code

This will save a lot of pain down the road. In particular, be careful with memory management- use smart pointers which automatically clean up the memory they point to when they go out of scope, rather than raw (traditional) pointers. For a short (10 page) intro to C++ best practices, please take a look at the attached document, cpp_best_practices.pdf .

Consult the artdaq-demo wiki

The structure of lbne-artdaq is very similar to the package from which it was derived, artdaq-demo. artdaq-demo is a "toy" artdaq-based data acquisition system which serves as a model for the software of running experiments. On artdaq-demo's wiki you can learn more about how an artdaq-based DAQ system works, and how you can develop fragment generators, etc. for your own experiment (in this case protoDUNE).

Use the DAQLogger class, rather than cout or cerr, for printing out information

This class is easy to use, and allows for a lot of useful behind-the-scenes work (filtering messages by severity level, reporting to RunControl, etc.). To learn more, look at Info on Using DAQLogger.

When pushing a feature to the develop branch, make sure the end result builds and runs correctly

How to do this is described in-depth here: When you've completed your feature

Base your fragment generator off of TPCMilliSliceSimulatorWithCopy

While in the artdaq-demo wiki users are encouraged to base their fragment generator off of that package's ToyFragmentSimulator, as the lbne-artdaq package already provides an example of the prototypical LBNE data millislice-microslice-nanoslice format, it's probably easier to base a fragment generator off of the TPCMilliSliceSimulatorWithCopy class.

Use the git flow model when creating a feature

"git flow" is a set of git extensions which makes it easy to work collaboratively within a very useful git workflow described (in-depth) here . In a nutshell, the idea is that there's a "master" branch used for official releases, a "develop" branch used to describe the latest version of the software which everyone within the project has in common, and different feature branches (e.g. "feature/coolidea1", "feature/coolidea2", etc.) which different members of the project may be working with to create their own specific features before merging into the develop branch. When the develop branch is agreed upon as being release-worthy, the changes on the develop branch are then merged into the master branch. And so on for the lifetime of the project.

To get started, execute the following commands after you've cloned the lbne-artdaq repository in your work area, and cd'd to its base:

source setupLBNEARTDAQ
setup gitflow
git flow init

You'll be prompted with a series of questions for the names of the branches to use for various purposes (the production release branch, the branch for collaborative development of the next production release, etc.). The production release branch should be named "master", the branch for developing the next production release should be "develop", and for all other questions just hit enter to get the defaults. For a useful cheatsheet to get you started using the git flow model of development, go to Daniel Kummer's git flow cheatsheet page .