Namespaces, file names,...
janssens-geert at telenet.be
Sat Sep 6 12:27:15 EDT 2014
On Saturday 06 September 2014 08:09:45 John Ralls wrote:
> 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#Gener
> > al_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  that snake is easier
> for non-native-English-speakers to parse?
I perceive no difference between the two styles. Abbreviations do make it harder to decode
variable or function names. But usually there is sufficient context for me.
> 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.
As I said, I don't have a strong preference. The point of keeping barriers for entry low is a
valid one. So agreed that we should keep the coding guidelines simple yet effective.
More information about the gnucash-devel