为什么没有人使用 STL 命名约定？ [关闭]

Question

Lots of C++ projects 使用某种驼峰式命名约定。唯一使用 STL 命名约定的项目似乎是 boost（正在为 STL 进行大量原型设计）。我知道有些项目早于 STL，但大多数新代码库（使用 STL）都坚持骆驼命名约定。

所以我的问题是：

• 为什么没有人使用 STL 命名约定？
• 您是否建议在新项目中使用 STL 命名约定而不是驼峰式命名？
• 我看到一些项目对某些'STL type' 类（limited_stack、simplify_type）使用 STL 命名约定，而对其他所有类使用驼峰命名约定。这看起来像是将基础架构与应用程序代码分开的好方法。你会推荐这样做吗？

（我知道命名约定已经被讨论到死了。但我认为这个问题以前没有回答过。尤其是拆分命名约定的想法，在我看来，值得讨论。）

Answer 1

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

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

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

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

看看其他语言。 C# 支持 CamelCase，首字母大写。为什么这比保留第一个小写更好？

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

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

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

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

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