Question

给定C ++模板类（或函数）定义：

template<typename T>
struct Foo {
  T member;
};

- 如果在一个更复杂的情况下我想让typename更具表现力，那么接受或避免使用哪种命名约定（以及为什么）。例子：

template<typename MORE_EXPRESSIVE_NAME>
struct More {
  MORE_EXPRESSIVE_NAME* p_;
  More(MORE_EXPRESSIVE_NAME* p);
  ...
};

template<typename MORE_EXPRESSIVE_NAME>
More<MORE_EXPRESSIVE_NAME>::More(MORE_EXPRESSIVE_NAME* p)
: p_(p)
{ }

或

template<typename MoreExpressiveName>
struct More {
  MoreExpressiveName* p_;
  More(MoreExpressiveName* p);
  ...
};

template<typename MoreExpressiveName>
More<MORE_EXPRESSIVE_NAME>::More(MoreExpressiveName* p)
: p_(p)
{ }

或

template<typename mr_exprs_nm>
struct More {
  mr_exprs_nm* p_;
  More(mr_exprs_nm* p);
  ...
};

template<typename mr_exprs_nm>
More<mr_exprs_nm>::More(mr_exprs_nm* p)
: p_(p)
{ }

Answer 1

命名约定的主要内容是一致性。无论您采用什么样的惯例，请在整个项目中保留它，因此如果您参加已经采用的项目，请坚持下去（如果没有，请重命名）。

话虽如此，在我看到的大多数命名约定中，所有大写字母通常都是为宏保留的，所以我绝对会避免使用它。

我自己更喜欢为模板参数命名，例如我命名类型或常量（取决于参数的类型），以保持一致性。在这种情况下，假设您使用More我也会使用驼峰案例。

至于你输入的内容，取决于：

对于小函数，我通常使用概念名称，例如FwdIt可能缩写为ForwardIterator，以提醒应该实现的类型
对于更大的类/函数，我使用概念或有意义的名称（依赖于业务）

Answer 2

MORE_EXPRESSIVE_NAME看起来像预编译常量。 mr_exprs_nm并不比Foo好多少。我投票支持MoreExpressiveName。有各种命名约定，但在这种情况下，简单的常识有助于找到最佳解决方案。

Answer 3

正如Matthieu M.所说，在命名约定方面，一致性比约定本身更重要。

那就是说，这是我使用的惯例：

CamelCase用于结构，类，typedef和amp;模板参数名称。基本上，任何类似于类型名称的东西都是CamelCase。

template<typename MoreExpressiveName> ...

我还将CamelCase用于static const全局

static const int MyMagicNumber = 42;

变量＆amp;的

underscore_lcase参数名称。成员变量也获得trailing_underscrore_。

template<typename MoreExpressiveName> 
More<MoreExpressiveName>::More(MoreExpressiveName* my_thing)
{
  my_thing_ = my_thing;
}

ALL_CAPS表示宏。

模板类型名称的大小写

3 个答案: