General
Usually names of class members defined with some rules. In ROOT fSomething, or mSomething or m_Something. There is no special rule for Sti. The style is actually mixed : some data members do not follow any rules but some follows a convention along _something. The latest is worse. Such rule is used in STL, especially to be different from user code. It is natural, that user code must not use this convention so debugging is rendered easier since it is easy to distinguish users members from system ones. To declare that Sti is a "system" code is too ambitious. We suggest to adopt “a” convention but not the one used by system classes and implementations.
Track model
In the above code snippet,
/// (signed curvature)*(local
X-coordinate of helix axis)
double _p2;
It is not clear what is "local X-coordinate of helix
axis". If it is a X coordinate of the center of circle, then
this choice could be bad for fast tracks.
Hit model
slightly too heavy 84 bytes(21 words). But it affects only memory usage, not performance or quality
Good, it is generic, does not depend of detector.
Helix
Calculator + Helix Fitter
They are based on radius of circle and coordinates of the center of circle. Such calculations is usually not precise nor stable for almost straigth tracks, where radius and coordinates of the center close to infinity. Typical example laser tracks. It may fail on them. Fit without errors. If it is used for first approximation, it is OK. If not, NOT OK.
StiDetector
It is a standard problem in many experiments and projects : reinventing of GEANT. If this pseudo GEANT structure would be created on the base of standard GEANT used in experiment, but simplified one, it would not be bad. But to create in parallel a different but so called "correct" detector description is practically impossible. So we never know how good reconstruction is for simulated events, and hence on real events too. Probably, bad pools (if observed) would not be the result of bad fitting but differences in the geometries.
By itself StiDetector is not general enough. GEANT3, GEANT4 can create structure not depending directly from experiment. The existence of classes StiEmcDetectorBuilder, StiFtpcDetectorBuilder, StiPixelDetectorBuilder, ... etc ... shows that detector description somehow are hard coded. The better choice is to develop an interface, with current implementation based on GEANT3, afterward it could be GEANT4, GEANT5 or something else, even own implementation.
StiHitContainer
Design is good. Implementation not bad but could be improved. Sometimes linear search is used that could be avoided.
MiniChain
This class supposed to be a replacement for the STAR framework. However, what this class is doing is very easy to do in STAR framework and nothing is new there. I think, the time spend for replacement or imitation of the STAR framework could be spend more productively in other areas. If STAR framework is bad for Sti task, it is better to ask STAR core group to improve it and provide feedback on missing functionalities.
Messenger
The same above comment applies to the Messenger class. May be Standard StMessenger is not good enough, but again it is better to ask Gene to improve it. Code re-use should be the focus wherever possible and the tracker qualified people should be spending their time on the tracker itself.
StiElossCalculator
Again, to calculate the energy loss, it is better to reuse some code from GEANT especially for simulated events. "The density effects are neglected" may be correct but professionals always are trying to reuse the approved code. Energy loss is not a so trivial task.