Namespaces, file names,...
christian at cstimming.de
Sun Sep 7 16:09:17 EDT 2014
Just for there record, here's my take on potential coding conventions:
Am Samstag, 6. September 2014, 11:06:13 schrieb Geert Janssens:
> > 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
> I also prefer the namespace name to be GnuCash in full. I don't have a
> strong preference regarding snake vs. camel either.
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
> Apparently lots of schemes exist.
> boost uses underscores.
Yes, boost and also the STL (std::...) uses underscores. For things that we
define in analogy to STL, we will probably re-use their underscore scheme also
regularly (such as typedef Xyz base_class; and typedef Xyz value_type;) in
case we define things that are commonly defined in STL as well.
> I also found the naming rules for Google which is a mixture of both:
> 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 also like the convention of type/class names starting with a capital. Other
than that, I have no strong preference between Camel and snake. Yes, in
general I would consider snake slighly easier to read for me as a non-English
native speaker, but I've worked with both and the difference is rather a
matter of taste.
I see some interesting part of a C++ coding convention, besides the general
naming scheme of types and varianles:
- Class member variables? From other projects I would propose a prefix such as
"m_", google has a "_" suffix.
- Member getters and setters (accessor and mutator methods)? From other
projects (and also Java) I would propose a prefix "get" and prefix "set", i.e.
getSomeVariable, setSomeVariable; Qt uses no prefix for the getter and "set"
for the setter: someVariable, setSomeVariable; google has no prefix for the
getter and "set_" for the setter: some_variable, set_some_variable.
> 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.
That's correct. However, as we (read: you) will create the C++ classes of the
gnucash engine types in the near future, we better decide up front whether we
want to have those types named with some consistency. In src/optional/gtkmm I
used my own preferred convention for the C++ wrapper classes, but when we
really define our core types, we probably better decide on our common
preferences. Hence, this discussion is not so much for a large style guide of
the majority of our future code, but rather for good standarization elements
when defining those commonly used types for ourselves.
More information about the gnucash-devel