Christian Stimming <christ...@cstimming.de> writes:
> Zitat von Derek Atkins <warl...@mit.edu>:
>>> 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
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
