Namespaces, file names,...

Derek Atkins warlord at MIT.EDU
Wed Sep 10 10:36:13 EDT 2014

Christian Stimming <christian at> writes:

> Zitat von Derek Atkins <warlord at>:
>>> I agree that filenames should reflect the class that they implement,
>>> when they do so, and I’ll add that in general a file should implement
>>> only one class. Capitalization is OK as long as one keeps in mind that
>>> the Mac file system is normally case-preserving but case-insensitive,
>>> so e.g. Account.h and account.h will map to the same file.
>>> I don’t think we want to give each directory its own namespace. I’m
>>> not even sure that we want any namespaces inside ‘gnucash’.
>> I kind of like the Ruby on Rails method, where the file name is the
>> lower-case snake form of the class name.  E.g., a class Account would be
>> in a source file account.[ch], a class ScheduledTransaction would be in
>> a file scheduled_transaction.[ch], etc.
> Glib/gtk has a scheme similar to what you mentioned from ruby, just
> with one extra third variation: The typedefs are CamelCase, the file
> names are with the same spelling but all-lowercase, and the function
> names are in snake form.

Sure, a typedef is effectively a class name.  So yes, I would expect
that to be CamelCase.

> And: Sorry to object, but I particularly dislike this scheme - it
> means the file names are always different from the class names. Why
> not making them completely identical? In that case, zero thoughts have
> to be spent on how to guess the correct file name for a given class.

Two reasons.  First: for file systems that are case-preserving but
case-insensitive, like on Mac and Windows.  In those cases if you do:

  #include "account.h"

It will work regardless of whether the file is account.h or Account.h.
But on Linux, of course, it will only work for the former filename.

I happen to prefer files to be all lower case for consistency.

Second, having a file named "scheduledtransaction.h" is harder to read
than "scheduled_transaction.h", at least IMHO.  Also, if you have
classes that are similar in name except for case you could have a
filename clash.  For example (to use an old joke from SNL):

class Therapists { ... };
class TheRapists { ... };

>> I agree that we don't need to have a directory for the namespace, and I
>> also don't think we need to have namespaces for each "module/library".
>> E.g., I don't think we need GnuCash::Engine::Account.  I suspect doing
>> so would just add complexity where it might not be warranted.
> I don't want to vote for extra namespaces, but I'd like to point out
> one technical reason for someone's preferences here: If the preferred
> tool of coding is something cmdline-based or emacs, chances are that
> extra directories mean extra typing work and are rather avoided. If
> the tool of coding is an IDE such as eclipse, qtcreator, or Visual
> Studio, the directories play only a minor role anymore (if visible at
> all in the project view) and chances are that they get to be used more
> often, for grouping of similar things and such. And in C++ (just as in
> java), adding extra namespaces for extra directories can be seen as
> the mapping between the file system and the compiler. In such a
> context, one wants to use gnc::engine::Account, knowing that it
> resides in the header file <gnc/engine/Account.h> on the disk, or
> gnc::backend::xml::XmlFile, knowing that it resides in
> <gnc/backend/xml/XmlFile.h>. You can always get rid of the namespace
> qualifications by using (no pun intended) "using namespace", but I
> know from my own learning curve that multiple namespaces seem rather
> smelly when coming from a C background. After years of C++ I got to
> like them, especially if they are implemented as a direct mapping from
> the directory structure on disk to the class structure in the
> namespaces. But that's just my personal take on this.

True.  For someone not familiar with the code it's nice to be able to
see where in the directory hierarchy a file might live if there is a
direct corellation between the class name and directory structure.

> Regards,
> Christian


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list