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

从 Boost Library Requirements and Guidelines ,

由于打算为C++标准库的下一次修订建议Boost的部分,Boost决定遵循标准库的约定。

没有技术上的原因。如果你忽略了文体上的原因,你可以写 scopedlock , istreamiterator 诸如此类。

可读性如果你可以称之为技术…空格通常是禁止的,下划线是最接近的匹配项。camel case很难阅读(通常是作为惯例保留给类的)。

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

我小时候更喜欢骆驼皮箱,有一个小显示器和一双小手。不过,我基本上都是来过。

主观上我发现代码中的下划线有点过分了。代码中对非字母数字符号的滥用已经够多了,我认为将它们引入标识符有点过头了。在我脑海中浮现出一个boost模板错误:

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 case的方法相比(我更喜欢这种方法):

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

我可以看到单独使用下划线的好处,但对于所有其他符号,我认为我们应该把重点放在使程序的阅读更接近英语,而不是强调ESE。

没有技术上的原因,但有原因。你必须同意我的观点,那就是读起来容易多了 scoped_lock 然后 scopedlock 但是 scopedLock 也会成功的。不过,带下划线更容易阅读,imho。

但是一个写得好的代码是一个易读的代码。这是知道如何编程的一部分。

没有技术上的原因。

C++中的变量名必须仅为

• 以字母或下划线开头
• 仅包含数字、字母(大写或不大写)和下划线

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

唯一的技术原因是可读性,因为使用camelcase可能会导致错误的解释,特别是在涉及所有大写字母缩写时。GPS插座会显示为GPSSocket。有一些更好的例子,但我的心理障碍阻止我写下来。:

如果你想获得技术性,没有理由,因为下划线是标识符的一个可行字符。

虽然从技术上讲没有区别,但也有可能是环境造成的问题。例如,如果包含windows.h,即使函数就是这样做的,也不希望将任何函数命名为textout。原因是,由于textout是win32 api中的一个宏,这个名称将被预处理器替换。因此,项目经理可能希望将非骆驼案例作为标准。

所以可能有技术上的原因,但没有语言本身的原因。它不像Java(它仍然这样做吗?)编译器强制您使用camel case。

就其本身而言,没有技术上的原因。但我确实有一个理由,除了我的油嘴滑舌“因为他们看起来很糟糕”。

我的原因是因为我发现用一种方便的方式区分成员变量和非成员变量是有用的。特别是当我将数据从局部变量传输到成员变量时,例如在构造函数中。便宜的例子:

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

如果你问我的意见,大多数可变命名方案都是可怕的,因为有太多的规则和太多的方式,他们打破。一个可怕的命名方案的典型例子是匈牙利语,但即便如此,我还是得到了一些有用的东西: m_ 成员变量的前缀有时很方便。不是太频繁,但经常足够我借用的想法,如果不是方法。

没有技术上的原因。这纯粹是文体上的。具体来说,C++从字母、下划线或美元开始标记所有符号。唯一的区别是如何声明它们。如果你愿意,你可以把你的“东西”类命名为 Thing , THING , thing , tHiNg ,甚至 T_h_I_n_G_$ 如果你想…这对编译器没有影响。然而,它 做 让其他人看到并使用你的代码时有所不同。如果你做得太过分(比如我列出的最后几个例子),你甚至可能会发现你的生命在某个时刻处于危险之中(愤怒的程序员可能是一件可怕的事情)。

除了语言强加的理由之外,没有任何技术上的理由支持或反对,在这种情况下,这种理由是不存在的。

这一原因是文体风格的边缘,但由于迄今为止还没有人提到过,所以我只需简单地说,在像C++这样一种区分大小写的语言中,下划线比大写更令人难忘。

例如,有时你可能会看到 scopedLock 而不是 ScopedLock . 如果你从不使用帽子,那就少了一件事。

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

我能想到的一个技术原因(特别是对于成员函数名)是允许duck类型。例如,可以在需要stl容器的情况下(在某种程度上)使用以下boost类:

• boost::ptr_容器和系列
• boost::多索引容器
• Boo::数组
• boost::动态位集(代替boost::位集)

嗯,对于您使用的语言,采用标准库的样式是非常合理的。如果是Java,则是SistDelk锁,如果是C++,则是SistEdE.OLD。如果是lisp,则为scoped lock。

无论如何,这并不重要。

当c被发明时,它在unix上使用,unix是从类似于打字机的终端操作的。有些终端既有大写字母又有小写字母,但有些终端只有大写字母。如果你想使用一个unix系统,但是所有漂亮的终端都已经被贪婪自私的同事占用了,那么你就不得不使用一个旧的终端。这就是为什么,如果您输入的登录名都是大写字符,那么unix假定您没有小写字符。每个小写字母显示为相应的大写字母,每个大写字母显示为一个星号,后面跟着它自己。

现在想象一下驼色大小写而不是下划线。

顺便说一句,c或多或少是基于pl/i的。pl/i被打到原本不支持小写的卡片上,最终可能被黑客攻击以支持小写,但不是以一种便于打孔的方式。此外,它通常是由不支持小写的打印机打印的,尽管有一些支持小写。所以小写字母被去掉了,camel大小写被去掉了,程序员被用来下划线。(除了COBOL程序员,他们习惯于在标识符中间减号,这意味着这是一个标识符,而不是这个减号减去一个减号标识符。)

pascal是后来发明的,当时的环境中小写字母更为常见,但仍不普遍。骆驼病例成为可能,因为帕斯卡是不区分大小写的。camel case之所以流行,是因为pascal不允许在标识符中使用下划线。

所以如果你喜欢驼峰病例和病例敏感度相结合,你就半途而废了。