按照变量的类型命名是一种不好的做法吗？

Question

我使用下划线命名风格（而不是驼峰命名法）对 C++ 进行编程，STL 和 boost 也使用这种命名风格。然而，由于类型和变量/函数都以小写命名，因此如下的成员变量声明将导致编译器错误（或者至少是麻烦）：

position position;

名为 position 的成员变量，其类型为 < em>位置。我不知道如何命名它：它通常是位置，但它也是对象的位置。在驼峰情况下，这对编译器来说没问题：

Position position;

但在 C++ 中它会导致问题。我不想切换到驼峰式大小写，使用匈牙利表示法或添加尾随下划线，所以我想知道：无论如何，像类型一样命名成员是一个好习惯吗？

在 C 中，为此使用神秘的单字母变量是很常见的：

int i;

但我发现有点神秘：

position p;

我可以使用变量命名的经验法则来避免这种情况吗？

如果您需要解决的话，我的代码中有更多示例：

mouse_over(entity entity) // Returns true if the mouse is over the entity

manager &manager; // A reference to the framework's manager

audio audio; // The audio subsystem

编辑：

我很好奇 Bjarne Stroustrup 本人是否对这个问题有话要说。显然，他没有，但他建议了可以解决我的编译器问题的编码约定：

例如，非标准库用户定义类型大写，非类型以小写字母开头

，这与 STL 和 boost 一致，所以我可能会使用它。然而，大多数人都认为无论编译与否，都应该避免这种命名。斯特鲁斯特鲁普也是如此：

选择仅大小写不同的名称是不明智的。

Answer 1

本地含义很少是该类型的良好唯一全局描述：

cartesian_point_2d position;  // rectangular, not polar coordinates
mouse_over(ui_entity entity); // not a business layer entity
xyz_manager& manager;         // what's a manager without something to manage?
audio_system audio;

Answer 2

为变量提供与其类型相同的名称几乎总是一个坏主意，因为这使得很难分辨哪些代码引用该类型以及哪些代码引用该变量。例如，考虑以下类：

struct position
{
    void operator()() { }
};

// later on, somewhere:
position position;

现在，如果我们看到一行代码使用：

position()

我们无法轻易判断它是构造 position 对象还是调用 position::operator() ()。我们必须返回并查看当前范围内是否存在名为 position 的对象。

命名约定是一件非常敏感、主观且有争议的事情。我只是建议选择一种以某种方式区分类型和变量的方法。就我个人而言，我选择将类型大写，并将变量保留为以小写字母开头。

如何区分它们并不重要（使用大写或尾部下划线的建议都很常见），只要您的用法保持一致即可。

Answer 3

根据变量的类型来命名变量确实是一种不好的做法。代码应该尽可能与类型无关。这意味着对实际类型的任何引用都应仅限于声明（同样，尽可能多）。尝试将类型信息嵌入到变量名中会违反该原则。不要这样做。

人们可能想要嵌入到变量名称中的是变量的语义。如“宽度”、“长度”、“索引”、“坐标”、“矩形”、“颜色”、“字符串”、“转换器”等。不幸的是，许多人在看到它时，错误地认为名称的这些部分旨在描述变量的类型。这种误解常常使他们在稍后的代码中陷入这种糟糕的做法（按照变量的类型命名变量）。

这种误解的一个典型的众所周知的例子就是所谓的匈牙利表示法。匈牙利表示法意味着在变量名称前添加描述变量语义的特殊统一前缀。在这种原始形式中，匈牙利表示法是一种非常有用的良好命名约定。然而，在许多实际情况下，它会被扭曲成完全不同的东西：在变量名前加上描述其类型的前缀。后者当然不是一个好主意。

Answer 4

是的，这是一个不好的做法。如果变量名具有较长的生命周期或重要的含义（临时变量也可以），则变量名应该更具体。请记住，C++ 的类型非常严格 - 您不能拥有一个变量，但又不确定它的类型是什么。例如，变量 Type 类型基本上仅意味着它没有名称。

Answer 5

就我个人而言，我将班级名称大写。

我不同意，在这种具体情况下，“选择仅大小写不同的名称是不明智的”。选择容易混淆的相似名称是不明智的。 PoSItIoN 和 PoSiTIoN 非常相似。 Position 和 position 不是。只要确保当您搜索代码时，您知道并且可以控制搜索时区分大小写还是不区分大小写。

如果我有一个只使用特定类型的一个变量的函数，那么我可能会以该类型来命名它，因为在英语中，如果某件事是“我们正在谈论的唯一位置”，我们会指它是“位置”。因此，变量名称可以合理地为position。

如果做不到这一点，在你的例子中我可能会选择：

position pos;  // pretty sure people will realise I don't mean "positron".

mouse_over(entity target) // Returns true if the mouse is over the entity

manager &fmanager; // A reference to the framework's manager

devices::audio audio; // The audio subsystem
audio self; // "this" audio subsystem
audio audio_out; // The audio subsystem I'm configured to use for output

最后一个例子应该表明这些问题可以通过命名空间来解决 - 在定义 audio 的命名空间之外，你可以安全地将其称为音频。在该命名空间内，经常对音频子系统进行操作的函数要么是音频类接口的一部分，而这些接口恰好是自由函数（在这种情况下，请使用诸如 self、< code>other、lhs、rhs），或者是某种具有音频子系统作为依赖项的分层设备或系统（在这种情况下，出于什么目的而依赖？）。

顺便说一句，entity 和 manager 对于类来说是糟糕的名称，因为它们都没有告诉您有关该类代表什么的任何信息。每一个离散的事物都是一个“实体”，虽然并非所有事物都管理其他事物，但“管理”却是极其模糊的。

Answer 6

这就是为什么我采用旧的 MFC 做法，在成员变量前添加 m_ 前缀，如“m_position”。许多 Java 人出于本质上相同的原因会做“thePosition”，尽管如果你当时指出相似之处，他们会变得有趣并对你咆哮。

Answer 7

我经常遇到同样的“问题”。我认为这是一个抽象问题：对于 Position，我建议进一步抽象并引入 Point 类型或类似的东西。或者指定ment是什么位置：

position mouse_pointer_pos;

Answer 8

简短且半错误的答案：如果您在一个地方有足够的变量需要非神秘的变量名称，则可能您的变量太多。

尽管在某种程度上我实际上不同意这一点。我认为它有一定道理，但仅此而已。

C++ 中的一些短变量名称只是传统的，人们知道它们的含义，因为他们已经使用 C/C++ 编程有一段时间了。使用 i 作为索引变量就是一个示例。

我认为变量名应该根据其用途来命名。职位是什么职位？经理管理什么？为什么音频子系统的这个特定实例需要存在？

结尾的 _ 表示法用于区分成员变量名称。当有人突然开始提到 x 时，看到 x_ 并知道它来自类，并且不是在封闭范围或全球范围。

Answer 9

遵循现有的指南，例如 Google 的 C++ 风格指南

您可以 意识到命名是一个重要问题，但根据我的经验
过多地思考它与不了解它一样有害。

我尝试过匈牙利语，但不喜欢它，我见过的大多数优秀程序员
知道不要用它。

我要说的要点是它使代码的可读性降低。

Answer 10

不，我偶尔会这样做，这不会在 Microsoft 世界中造成问题。例如，

class compiler
{
    symbol_table symbol_table;
};

从未引起任何混乱。顺便说一句，我称我的猫为“猫”，这也没有引起混乱。

Answer 11

在我看来，这种命名约定的最大问题是程序员不清楚表达式是指类型还是对象。消除这种歧义的一种方法是将代码包装在命名空间内（理应如此）并使用显式限定，即使在内部使用时也是如此：

namespace my_ns {

struct audio { ... };
struct string { ... };

// Internal function whose logic doesn't require explicit qualifications.
void do_something()
{
    // Use explicit qualification nevertheless.
    my_ns::audio audio;
    audio.play("impenetrable.sd2"); // okay

    my_ns::string string;
    string.size();          // okay
    // string{}.size();     // oof, tryna re-instantiate object? compilation error
    my_ns::string{}.size(); // okay, size of just created temporary string
}

}

这非常类似于使用标准类型（例如 std::stringstd::string）的方式代码>.由于所有用户定义的类型都将使用其名称空间进行限定，因此类型和对象之间不会存在歧义。当然，这样做的缺点是更加冗长：

namespace my_ns {

struct audio {
    // Using explicit qualification; pretty verbose.
    void play(my_ns::string a1, my_ns::string a2, my_ns::string a3);

    // Without explicit qualification; saves 21 characters.
    void play(string a1, string a2, string a3);
};

}