Namespaces, file names,...

[John Ralls]

On Sep 8, 2014, at 11:22 AM, Christian Stimming <christian at cstimming.de> wrote:

> Am Sonntag, 7. September 2014, 15:10:13 schrieb John Ralls:
>>> I strongly prefer namespaces in all-lowercase. I have somewhat a
>>> preference
>>> for "gnc" as namespace name, but we are an application anyway and not a
>>> library, so we're basically free to choose whatever we want as interface
>>> naming schemes.
>> 
>> Any particular reason for the all lowercase preference? Not that it matters,
>> gnucash and GnuCash are equally unique.
> 
> I think one relationship wasn't mentioned so far: The filenames and the 
> corresponding namespace and class names. I think both should be as identical 
> as possible - similar to Qt, different from glib.
> 
> Namespaces in lowercase gives also directory names in lowercase. Class names, 
> well, should appear in the file names IMHO as unchanged as possible. I prefer 
> both with the first letter in capital, but I know this causes occasionally 
> some hassles on windows systems, as those colleagues notoriously forget to add 
> their include directives with the correct case sensitivity. Other people argue 
> that file names should be all lowercase in general. Both views exist.

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 don't mind tagging member variables, and I find m_varName to be clearer
>> than just sticking an underscore at the end. One can go one step further
>> and tag static members with a c_ or an s_, while being aware that static
>> members, just like any other static or global variable, require extra
>> synchronization and so should be avoided as much as possible.
> 
> Ok for the prefix. However, "static class members" are not at all evil. 
> They're a normal part of the language and needed for modelling certain aspects 
> of a program. What is evil are global variables. But static class variables 
> are just fine - they are fixed into their scope and have access rules. They 
> are simply needed occasionally. Nothing that necessarily has to be avoided.

Static member variables, a.k.a. class variables, are indeed a core feature of the language. When using them one just has to be aware that access must be synchronized; fortunately C++11 added some nice sync functions to the standard library that make that reasonably easy. However, synchronization is a bit expensive and so it’s better to avoid it if possible.

There are times when regular member variables need to be synchronized too — any time one has a shared_ptr or naked pointer running around all access to its members must be synchronized. 

The same is true of file-scope statics, which aren’t globals, but their existence seldom reflects good C++ design. In general a file-scope static should be a member variable; in some cases a class variable. 

Regards,
John Ralls