Namespaces, file names,...

[John Ralls]

On Sep 6, 2014, at 2:06 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On Friday 05 September 2014 12:13:49 John Ralls wrote:
> > On Sep 5, 2014, at 10:02 AM, Mike Alexander <mta at umich.edu> wrote:
> > > On Sep 5, 2014, at 11:26 AM, Buddha Buck <blaisepascal at gmail.com> wrote:
> > >> When every method name has to be Hungarian-notated to work with
> > >> pseudonamespaces, short namespace abbreviations make sense.
> > >> 
> > >> But with true namespaces, using directives, and namespace aliasing
> > >> available in C++, I see benefits in readability to use full length
> > >> names for namespaces (like GnuCash::Account instead of gncAccount
> > >> or Gnc::Account. There's less likelyhood of collision with, say, a
> > >> library written to support the General Nutrition Centers (GNC)
> > >> chain of stores.
> > >> 
> > >> While I personally prefer snake_case to camelCase, I think that the
> > >> idiomatic C++ tends to use camelCase.
> > > 
> > > I agree with both points.  I think the namespace name should be
> > > spelled out in full and camel case is more often used in C++.  I
> > > happen to prefer it, but perhaps that’s just because I’ve used it
> > > more.
> > Yes, using GnuCash is less ambiguous that Gnc. Sold. For the record I
> > don’t care about snake vs. camel as long as we pick one.
> > 
> John, thanks for elaborating on the differences between c and c++ concerning namespaces.
>  
> I also prefer the namespace name to be GnuCash in full. I don't have a strong preference regarding snake vs. camel either.
>  
> Apparently lots of schemes exist.
> boost uses underscores.
>  
> Qt uses camel and goes even further: class types start with a capital letter and each word is capitalized,  while for member functions each word is capitalized except for the first one.
>  
> I also found the naming rules for Google which is a mixture of both:
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Naming_Rules
>  
> The latter takes more discipline while coding. On the other hand it helps distinguish what a word means. Is it a variable, a type a function ? The style it's written in helps distinguish in this case.
>  
> Personally I like such a scheme.

I don't. It's immediately apparent what an identifier is from its context: One doesn't call variables or assign to functions. It can be helpful to distinguish member variables from locals and parameters, but that's about it for encoding meaning into identifier names and formats. Consistency and readability are much more important. A lot of style guides argue against abbreviated names on the grounds that they're ambiguous, but I think it's more significant that they're easier to read, though that might hold only if one is fluent in reading the language the identifier is written in. On that vein, anyone want to comment on Stroustrup's claim [1] that snake is easier for non-native-English-speakers to parse?

It's also the case that the longer and more complicated the style guide the less likely it is that it will be followed. That's partly down to self discipline but more to the volunteer nature of open source projects. We don't want to chase away contributors by making them read and follow a 100-page style document.

Regards,
John Ralls

[1] http://www.stroustrup.com/bs_faq2.html#Hungarian