Zitat von Derek Atkins <[email protected]>:
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.
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.
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.
Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
