所以我的问题是：
>为什么没有人使用STL命名约定？
>您是否建议在新项目的基础上使用STL命名约定
>我已经看到一些项目使用STL命名约定为一些“STL类”类(limited_stack,simplify_type)和骆驼案例的一切.这似乎是一种将应用程序代码分离到基础架构的好方法.你会建议这样做吗？
(我知道命名约定已经被讨论为死亡,但我认为这个问题以前还没有回答过,特别是在我看来,命名约定的想法是值得讨论的.)
解决方法
一个约定就是这样：一个约定而不是使用哪一个,而是可以为您和程序员输入一个可读性和舒适性的程序员来保持您正在使用的代码.
我在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反映出次要的问题:).
