Question

在Boost库中的（例如）scoped_lock等名称中使用下划线是否有任何技术原因？为什么不称它为'ScopedLock？

请注意我不是在询问文体原因。

Answer 1

来自Boost Library Requirements and Guidelines，

鉴于有意为下一版C ++标准库提出部分提升，boost决定遵循标准库的约定。

Answer 2

没有技术原因。如果你忽略了文体原因，你也可以写scopedlock，istreamiterator等。

Answer 3

可读性如果你可以称之为技术......空间通常被禁止，而下划线是最接近的匹配。骆驼的情况很糟糕（通常是作为惯例保留给班级）..

Answer 4

下划线通过在单独的单词之间创建更多空间来改善与人类神经硬件的接口。

我小时候喜欢看camelcase，有一个小显示器和小手。不过，我大部分时间到了。

Answer 5

主观上，我发现代码中有一些矫枉过正。在代码中有足够的滥用非字母数字符号，我认为将它们引入标识符有点过头了。在我的脑海中，考虑一下来自增强模板错误的摘录：

Derived=boost::transform_iterator<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>>,
Base=boost::counting_iterator<size_t>,
Value=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::cv_value_type,
Traversal=boost::use_default,
Reference=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::reference,
Difference=boost::use_default

与已转换为Pascal案例的以下内容（我更喜欢这种方法）：

Derived=boost::TransformIterator<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>>,
Base=boost::CountingIterator<SizeT>,
Value=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::CVValueType,
Traversal=boost::UseDefault,
Reference=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::Reference,
Difference=boost::UseDefault

我可以看到单独使用下划线的优势，但是我想我们应该专注于制作更接近英语而不是下划线的程序。

Answer 6

没有技术原因。

C ++中的变量名只能

以字母或下划线开头
仅包含数字，字母（大写或不大写）和下划线

使用this_way或ThisWay只是风格问题。

Answer 7

没有技术原因，但有一个原因。您必须同意我的看法，scoped_lock然后scopedlock更容易阅读，但scopedLock也会这样做。然而，下划线更容易阅读，恕我直言。

但是编写良好的代码是一个清晰的代码。这是了解编程的一部分。

Answer 8

唯一的技术原因是可读性，因为使用CamelCase可能会导致错误的解释，尤其是在引用所有大写的缩写时。 GPS插座将作为GPSSocket出现。有一些更好的例子，但我的心理障碍使我不能写下来。： - （

如果你想获得技术支持，没有理由因为下划线是标识符的可行字符。

Answer 9

虽然从技术上讲没有区别，但环境可能导致问题。例如，如果你包含windows.h，你就不想命名任何函数TextOut，即使这是函数的功能。原因是由于TextOut是win32 API中的一个宏，因此该名称将被预处理器取代。因此，项目经理可能希望将非骆驼案作为标准。

因此可能存在技术原因，但语言本身没有任何理由。它不像Java（它仍然这样做吗？），编译器强迫你使用驼峰式的情况。

Answer 10

恕我直言，为您使用的语言采用标准库的风格是非常合理的。如果它是Java，则为scopedLock，如果是C ++，则为scoped_lock。如果是Lisp，那就是scoped-lock。

无论如何，这并不重要。

Answer 11

当C被发明时，它在Unix上使用，而Unix则是从类似打字机的终端操作的。有些终端有大写和小写字母，但有些终端只有大写字母。如果你想使用一个Unix系统，但所有漂亮的终端已经被你那些贪婪的自私同事所占据，你就会陷入旧的终端。这就是为什么，如果你输入所有大写字符的登录名，Unix假定你没有小写。每个小写字母显示为相应的大写字母，每个大写字母显示为星号，后跟其自身。

现在想象一下骆驼套管而不是下划线。

顺便说一下，C基于PL / I或多或少松散。 PL / I被打成了最初不支持小写的卡片，并且最终可以被黑客攻击以支持小写，但不是以打孔友好的方式。此外，它通常由不支持小写的打印机打印，尽管有一些打印机。因此，小案例已经结束，骆驼案已经结束，程序员习惯于强调。（除了Cobol程序员，他们习惯于在标识符中间使用减号，这意味着这个标识符不是这个减号，而是减去减号标识符。）

Pascal是后来发明的，在一个小写字母更常见但仍然不普遍的环境中。骆驼案成为可能，因为Pascal不区分大小写。骆驼案开始流行，因为Pascal不允许在标识符中使用下划线。

因此，如果您喜欢结合区分大小写的骆驼案例，那么您已经过了一半。

Answer 12

我能想到的一个技术原因（特别是成员函数名称）是允许鸭子打字。例如，可以使用以下boost类（在某种程度上），其中需要一个STL容器：

boost :: ptr_container和family
boost :: multi_index containers
升压::阵列
boost :: dynamic_bitset（代替boost :: bitset）

Answer 13

嗯，不是编译器，但是prefast规则集有时会尝试强制执行命名约定。坦率地说，这么多公约真的令人困惑;特别是当需要支持旧代码以及用多种语言编写新代码时。

Answer 14

这个理由掩盖了风格的边缘，但由于到目前为止还没有其他人提到这一点，我只想在像C ++这样的区分大小写的语言中添加它，下划线比大写更令人难忘。

例如，有时您可能会看到scopedLock而不是ScopedLock。如果你从不使用大写字母，那么只需要少量工作。

Answer 15

除了语言所强加的技术理由之外没有任何技术理由，在这种情况下，该语言不存在。

Answer 16

本身没有技术原因。但我确实有其他理由，因为他们看起来很棒。“

我的理由是因为我觉得以方便的方式区分成员变量和非成员变量很有用。特别是当我将数据从局部变量传递到成员变量时，例如在构造函数中。便宜的例子：

class Socket
{
public:
  Socket(const sockaddr_in& group)
  :  group_(group)
  {
  }
private:
  sockaddr_in group_;
};

如果你问我的观点，大多数变量命名方案都很糟糕，因为有太多的规则和太多的分解方式。一个可怕的命名方案的典型例子是匈牙利语，但即便如此，我确实采用了一些有用的东西：成员变量的m_前缀有时会派上用场。不经常但经常足以让我借用这个想法，如果不是方法。

Answer 17

没有技术原因。它纯粹是风格。具体而言，C ++查看以字母，下划线或美元符号开头的所有符号。唯一的区别是如何宣布它们。如果您愿意，可以将“事物”类命名为Thing，THING，thing，tHiNg，甚至是T_h_I_n_G_$，如果您愿意的话......它对编译器没有任何影响。但是，它确实会对将要查看和使用您的代码的其他人产生影响。如果你把它放得太远（比如我列出的最后几个例子），你甚至可能会在某些时候发现你的生命处于危险之中（一个愤怒的程序员可能是一件可怕的事情）。

包含下划线的名称的技术原因？

17 个答案: