On Tue, Jul 5, 2011 at 3:37 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Fri, 2011-06-24 at 13:11 +0200, Chris Kühl wrote:
> One question I do have about style is what is the preferred file nameing
> scheme. Some are in module-class-name form, others in module-ClassName
> form, and still others in ClassName form. I'll be happy to make my new
> files reflect the desired scheme.
I forgot to answer this. I don't have a strong opinion about this. I'm
not a fan of the "one class per file" paradigm. IMHO it leads to a
needless proliferation of files. I prefer to group related classes in a
single header and implementation file.
There are definitely some classes that can be moved merged with there
larger associated files. AutoTerm is one that comes to mind; it's only
used in DBusServer. Also, some of the utility type classes like TImer
and Timeout can easily be placed in the same file. I'd prefer to keep
non-utility classes that are used in multiple classes in there own
files, though.
On the other hand, it is more obvious where code is to be found when
the
file name is the same as the class name, once one knows the class name.
In my view this is very helpful to get a quick overview of the program.
Of course, this also wins you a few seconds on compile time. After
doing a full compile on both the master and dbus-server-reorganization
branches, I then touched syncevo-dbus-server.cpp on both branches and
reran make from the src directory. It took ~17s to compile on master
and ~7 on d-s-r. A pretty nice time savings.
We have now gone from one extreme of having ~25 classes in one file
stretching > 6000 lines, to the other of having ~40 .h/.cpp files for
those same ~25 classes. I'm happy to merge a few of these but in
general I think keeping the classes in separate files is a good thing.
Shall I merge the obvious candidates?
Cheers,
Chris