为什么没有人使用 STL 命名约定？
很多 C++ 项目 使用某种驼峰命名约定。唯一使用 STL 命名约定的项目似乎是 boost（其中正在完成许多 STL 原型设计）。我知道有些项目早于 STL，但大多数新代码库（使用 STL）都坚持驼峰式命名约定。
所以我的问题是：
- 为什么没有人使用 STL 命名约定？
- 您是否建议在新项目中使用 STL 命名约定而不是驼峰命名法？
- 我见过一些项目对某些“STL 类型”类使用 STL 命名约定 (limited_stack、simplify_type) 以及其他所有内容的驼峰式大小写。这看起来是将基础设施与应用程序代码分开的好方法。你会建议这样做吗？
（我知道命名约定已经被讨论死了。但我仍然认为这个问题以前没有得到解答。尤其是在我看来，拆分命名约定的想法值得讨论。）
Lots of C++ projects use some sort of camel case naming convention. The only project using the STL naming conventions seems to be boost (where much prototyping for the STL is being done). I know that there are some projects that predate the STL, but also most new code bases (that use the STL) stick with the camel case naming convention.
So my questions are:
- Why is no one using the STL naming conventions?
- Would you recommend using the STL naming convention over camel case for a new project?
- I have seen some projects use the STL naming conventions for some 'STL type' classes (limited_stack, simplify_type) and camel case for everything else. This looks like a good approach to separate infrastructure from application code. Would you recommend doing this?
(I know that naming conventions have been discussed to death. Still I think that this question has not been answered before. Especially the idea of splitting naming conventions is, in my opinion, worth discussing.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，我要强调的是，我的答案非常主观，仅基于我的经验，没有任何外部数据或资源的支持。
约定就是这样：约定。重要的不是您使用哪一种，而是哪一种对您和维护您当前正在使用的代码的程序员来说可读且打字舒适。
我在 C++ 中使用驼峰命名法，因为它在视觉上更悦目，而且我已经习惯了。另一方面，我在 C 中使用下划线和小写函数名称 - 这成为一种区分我使用哪种语言的简单方法。
其他程序员肯定会给你其他的理由——其中大部分或多或少都是主观的，对他们或他们所属的开发团队来说都是如此。
看看其他语言。 C# 倾向于驼峰命名法，第一个字母大写。为什么这比将第一个小写更好？
使用 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 与下划线是次要的事情： ）。First of all, let me stress that my answer is pretty much subjective, based on my experience only, not backed with any external data or resources.
A convention is just that: a convention. It matters not which one you use, but rather which one is readable and comfy to type for you and the programmers that get to maintain the code you're working with at the moment.
I use CamelCase in C++ because it's more visually pleasing for my eye and because I'm just used to it. On the other hand, I use underscores and lowercase function names in C - it's become sort of a simple way of distinguishing which language has been used for me.
Other programmers will most certainly give you other reasons - most of which will be more or less subjective, true for them or the dev temas they're members of.
Look at other languages. C# favours CamelCase, with the first letter capitalised. Why is that better than leaving the first one lowercase?
PHP programmers that use Zend framework are also familiar with Zend naming conventions: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html.
Drupal API is PHP too - but uses underscores, lowercase letters and module/theme-specific prefixes.
Libraries, frameworks and even entire languages may have naming conventions that for some reason are favoured by their makers. That does not force you to quit using your usual naming convention :). So, all in all, I think the answer to your question can be put in such a silly manner: just because :D. Because the individual programmers feel comfortable with it.
As for the second question: no, I would not recommend using any convention over another for any project. Choose what's best for you. The only situation where you have no choice is when you're in a dev team that for some reason wants to stick to a single convention (such as a consistent API).
Third question: yes, you can view it this way. I usually prefix my classes so it's pretty much obvious that
UmbraModuleorTCODConsoleare part of Umbra or libtcod API. As for STL, I prefer not namespacing it. Prefixing everything withstd::*is a very clear indication of whether it's part of a different library or not, thus the infrastructure/application code is clearly distinguished - leaving the CamelCase vs. underscores a secondary matter :).