On Saturday 06 September 2014 08:09:45 John Ralls wrote: > On Sep 6, 2014, at 2:06 AM, Geert Janssens <[email protected]> wrote: > > On Friday 05 September 2014 12:13:49 John Ralls wrote: > > > On Sep 5, 2014, at 10:02 AM, Mike Alexander <[email protected]> wrote: > > > > On Sep 5, 2014, at 11:26 AM, Buddha Buck <[email protected]> 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 [1] 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. Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
