On Sep 8, 2014, at 11:22 AM, Christian Stimming <christ...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
