为什么没有人使用STL命名约定？

Question

大量 的 C++ 项目中使用某种形式的驼峰命名约定.使用STL命名约定的唯一项目似乎是提升(对STL进行了大量原型设计).我知道有一些项目早于STL,但也有大多数新的代码库(使用STL)坚持使用驼峰案例命名约定.

所以我的问题是:

• 为什么没有人使用STL命名约定？
• 您是否建议在新项目中使用针对驼峰案例的STL命名约定？
• 我已经看到一些项目对某些'STL类型'类(limited_stack,simplify_type)使用STL命名约定,并为其他所有类使用驼峰大小写.这看起来是将基础架构与应用程序代码分开的好方法.你会建议这样做吗？

(我知道命名约定已经被讨论过了.我仍然认为这个问题以前没有得到解答.在我看来,特别是分割命名约定的想法值得讨论.)

Answer 1

首先，我要强调的是，我的答案非常主观，仅基于我的经验，没有任何外部数据或资源的支持。

约定就是这样：约定。重要的不是您使用哪一种，而是哪一种对您和维护您当前正在使用的代码的程序员来说可读且打字舒适。

我在 C++ 中使用驼峰命名法，因为它在视觉上更悦目，而且我已经习惯了。另一方面，我在 C 中使用下划线和小写函数名称 - 这成为一种区分我使用哪种语言的简单方法。

其他程序员肯定会给你其他的理由——其中大部分或多或少都是主观的，对他们或他们所属的开发团队来说都是如此。

看看其他语言。C# 倾向于驼峰命名法，第一个字母大写。为什么这比将第一个小写更好？

使用 Zend 框架的 PHP 程序员也熟悉 Zend 命名约定：http://framework.zend.com/manual/en/coding-standard.naming-conventions.html。

Drupal API 也是 PHP - 但使用下划线、小写字母和特定于模块/主题的前缀。

库、框架甚至整个语言可能具有出于某种原因受到其制造者青睐的命名约定。这并不强迫您放弃使用通常的命名约定:)。所以，总而言之，我认为你的问题的答案可以用这样一种愚蠢的方式来表达：只是因为：D。因为个别程序员对此感到很舒服。

至于第二个问题：不，我不建议在任何项目中使用任何约定。选择最适合您的。您别无选择的唯一情况是当您所在的开发团队出于某种原因想要坚持单一约定（例如一致的 API）时。

第三个问题：是的，你可以这样看。我通常为我的类添加前缀，因此很明显 或UmbraModule是TCODConsoleUmbra 或 libtcod API 的一部分。至于STL，我更喜欢不给它命名空间。为所有内容添加前缀std::*可以非常清楚地表明它是否是不同库的一部分，因此基础设施/应用程序代码可以清楚地区分 - 将 CamelCase 与下划线留给次要问题:)。