Is there a good/widely adopted c++ template coding convention/standards?

I like coding standards. When writing C++ I love coding standards. A good coding standard adds context to the language, making the hard to parse a little bit easier.

There are a few commonly practiced standards that I think everyone is at least a little bit familiar with:

• Member variables prefixed with 'm' or 'm_'
• Class prefix (generally project specific, ie in Qt all class names are prefixed with 'Q')
• Include guard conventions like "take the filename in all caps, replace '.' with '_' "
• The rule of three

There are lots of little C++ rules like this. Unfortunately I've never managed to find guidelines like this relating to templates. I think the most popular name for a template argument is 'T', but it's meaningless and unless the template is obvious it can make the code even trickier to read.

Anyway, the core problem I have is that templates are hard to read and I think some convention cou开发者_如何学运维ld be used to make them easier to read. Does anyone know of a widely applied convention that makes templatized code easier to read?

Just adding my grain of salt. I think the two most important libraries in the world of C++ programming are the Standard Template Libraries and the Boost Libraries. I personally try to mostly conform to the kind of notation that is predominant in these libraries. That is, underscore-separated lower-case names for classes, functions, data members, typedefs, enums, etc., and CamelCase (no underscore separation) for template arguments. Typically, you want to also have sensible names for template arguments. A good practice is to give them the name of the concept they should be implementing (e.g. a template argument which should be an iterator that implements ForwardIteratorConcept should be named ForwardIterator).

The conventions that you mentioned ("m" for members and Capital-letter-starting names for classes) is a sort-of pure Object-Oriented Programming convention ("pure" is meant as in: without any other programming paradigms like generic programming or template meta-programming). It is mostly used in Java (or by Java "natives" who are programming C++). I personally don't like it and know few people who do. I'm always a bit annoyed when working within a framework or project that adopts this notation, it de-tones with the standard libraries, boost libraries, and the overall proper usage of namespaces.

My recommendation is to always look at a language's standard libraries for examples of set a coding convention. The result is that your code will read more naturally for the language in which it is written. Basically, write C++ that looks like it could be part of the ISO C++ documents.

For C++, the standard containers, iterators and algorithms have many templates you can use as examples.

As a counter example, using camel case will make your C++ code to read like Java. When you end up using things from the standard library along side your own code, it will look weird.

That said, there are two exceptions to consider. Firstly, if you already have a large code base, follow what's already there: a mix of styles is confusing. Secondly, there are excellent libraries, such as Qt, that do not follow the style of the standard libraries, they are also worthy as examples of coding standards.

* Member variables prefixed with 'm' or 'm_'

Questionable.

* Class prefix (generally project specific, ie in Qt all class names are prefixed with 'Q')

Terrible. Was a necessary practice back in the day.

Big three isn't really a standard either and has pretty much been superceeded as a good practice by the Big Two (because using RAII for pointers negates the necessity of a destructor even when you need Copy ctr and assignment).

At any rate....

You need to differentiate your template parameters from normal code. Thus, you should use a naming convention that you are not using in standard code for template parameters. One good method, used by a good many, is to use CamelCase for template parameters. Another important aspect is, since C++ doesn't enforce concepts at all, to name your parameters after the concept they expect. ForwardIter thus makes a good parameter name for a parameter than should be a forward iterator.

Of course, if you're already using CamelCase for your class names (Java programmers - blech :p) then you should use something else.

When you get into complex instantiations and such then you need to use some method of declaring your template instantiations in multiple lines. When metaprogramming you also often need to split things up into multiple lines and/or multiple types/templates. It's one of those learn as you go things. I like the following method:

template < typename MyParams >
struct my_metafunction
  : mpl::if_
    <
      check // probably wouldn't actually split this one since it's trivial...but as example...
      <
        MyParams
      >
    , some_type_expression
    , some_other_type_expression
    >
{};

There are no "common conventions" for names. Even the conventions you mention aren't as common as you might think. I can't think of anyone using m or m_ prefix for class member data other than a subset of Windows developers. Similarly for prefixing class names.

Conventions of this sort are very project-specific. You agree about them in a project and move on. When you start a new project it's perfectly alright to have new conventions if you so desire. If you lack imagination or confidence to pick your own conventions then buy Herb Sutter and Andrei Alexandrescu's C++ Coding Standards book. In fact, you should really read it because it deals with far more effective conventions than naming conventions. With things that actually matter.

If it at all helps I sometimes see people choosing for template parameters short names that start with a capital letter. E.g., template<class Ch, class Tr>. Look in your compiler's standard library for inspiration.

Take a look at Boost if you want to see their coding convention.

Like the others say, it depends on the project coding style. I like using lowercase letters separated with under score while coding. And for the harmony I use lowercase letters for template parameters too. To distinguish them from the others, I start with underscore and end with "_t".

`

template<typename _encoder_t>
class compression
{
typedef typename _encoder_t::settings settings_t;
...
};

`