hmm, if something is in eutelescope:: namespace it should be preceeded also
with EUTel in the name
if it's a processor the next thing should be Processor, so a eutelescope ::
processor should be called EUTelProcessor - we have been following this
guideline for quite a while now.

from the none Processors - we have the Geometry description class with
navigation - should act a singlton (only one geometry description for
everything)
what about none Geometry objects and functions ... EUTelUtility - so far
it's not obvious that it should also be a singlton, as introducing static
objects should be avoided just as of global parameters, unless there is a
clear case to do so. Hit encoding and decoding seems to be a good argument
-> how about EUTelDataUtilities singleton class?

if it's a static thing, should it be reflected in the name? perhaps yes.
prefix "_single" in the name of the static object?


On Mon, Jun 2, 2014 at 11:22 AM, Igor Rubinsky <igorrubinsky@googlemail.com>
wrote:

> definitely! the name of a function, class, file should clearly explain
> where it comes from and why it has been introduced.
>
>
> On Mon, Jun 2, 2014 at 10:26 AM, tbisanz <notifications@github.com> wrote:
>
>> In src/EUTelCorrelator.cc:
>>
>> > @@ -150,6 +154,11 @@ void EUTelCorrelator::init() {
>> >    // usually a good idea to
>> >    printParameters ();
>> >
>> > +  // Getting access to geometry description
>> > +  std::string name("test.root");
>>
>> Maybe we should start using usefull names here - I know its called like
>> test.root everywhere but this should be changed
>>
>> —
>> Reply to this email directly or view it on GitHub
>> <https://github.com/eutelescope/eutelescope/pull/68/files#r13274727>.
>>
>
>