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 > namespaces. > > 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 naming schemes. > 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: > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Namin > g_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 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. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
