其实可以不用那么c++

所谓编程语言本质也是一门语言，目的是表达自己的思想，虽然目标是机器而不是人，但是相信我，会真正看语言本身的终究还是人。所谓优雅的代码就是严谨的表达出自己的思想，并且易于维护的。如果你写一篇文章满是之乎者也，但是别人都不懂，那么即便你知道“茴”字的六种写法又如何？会有人觉得你是国学大师吗？在我看来代码易于理解比什么都重要，只有代码容易理解了，之后维护和改bug也才容易，后期他人维护起来也不会捅什么娄子。而性能上优势绝不是体现在一两处语法上面，而是更加宏观的层面上。

例子1：滥用命名空间

c++引入命名空间无可厚非，正常使用也可以清爽不少。比如cocos2d-x，如果你的代码中没有与之冲突的名称，那么可以在实现文件中放心的using namespace cocos2d，如果有的话，也可以使用namespace cc = cocos2d来简化代码。这都是很好很好的。但是有些人看了几篇c++的教程就滥用命名空间，一个不大的项目中N个命名空间，更可怕的是还在头文件中using namespace，在命名空间内部使用class xxx;这样的类生命。这样的问题，一是人肯定看不懂，同样是Font，存在于几个命名空间中，鬼才知道哪个对哪个。二十编译器也可能看不懂，即便恰好是gcc编译过了，vs也不见得编译过，即便都能编译过，那稍微修改下工程合并一下项目文件也会出乱子。写代码而已，何必给自己找麻烦呢？加个前缀会恶心到哪里去？

我的观点是，可以使用命名空间，但是一个项目（比如Ogre cocos2d-x这样的规模）最多一两个，并且不要在自己的项目中还靠命名空间来区分类。命名空间的存在只是相当于对自己的代码的一个保护和封装，别人使用时可以方便的拿过来用，而不会产生一些恶心的全局变量或者函数的冲突。

例子2：项目中文件命名习惯和头文件引用习惯的问题

很多人命名文件时不喜欢加项目标志和文件夹标志，这样最大的问题就是会造成很多同名文件，无论是自己项目中，还是和其他项目都可能引发冲突。比如在render文件夹下有一个util.cpp util.h，在network文件夹下也有一个util.cpp util.h，那么这两个文件必须存在于不同的工程中，否则编译出的obj文件会冲突，链接器会自动忽略其中之一。vs在编译文件时是不会带着文件夹路径的。

还是那句话，加上文件路径标志会恶心吗？我反而觉得这样是恶心的，比如va中一搜索util，出来三五个util.cpp，不自己看看还真不知道要找的是哪个，不如直接加上render_util.cpp，network_util.cpp,这样来的直观。希望cocos2d-x不会那天抽疯了把CC的文件夹前缀也给去掉了。

头文件也是如此。过短的命名造成的后果就是设置头文件查找路径的时候要格外小心，否则很容易调用到错误的文件上。这里我认为，除开特殊情况（比如平台文件不同），否则项目中的头文件包含都要是相对于一个固定路径的完整路径。

例子3：奉stream为圭臬

看过几本c++教程的，都知道标准库中的stringstream iostream等等，当然是更加c++，更加可扩展，更加类型安全等等。但是在我看来那些都是玩具，又难用，又没有必要用。fopen什么的要比iostream好用多了，printf也要比iostream漂亮多了，要多反人类才会喜欢这样的打log的写法啊(stream << "正在打第" << i << "关" << "玩家" << id << endl)。同样的sscanf snprintf也要比stringstream实用强大。用标准库能写一两百行的代码，其实一个vsprintf就搞定了。至于类型安全，如果我需要靠虑类型安全我也会使用boost::format，就像我绝对不会实用bind1st一样，我也不会使用这些东西。c++标准库看着能将一本600页的书，其实学会vector map等容器的正确用法和相关算法就足够了，我相信现在还没有那本讲标准库的教程里面会有bind function thread shared_ptr 这些东西，但是如果你学习了stream却又不知道bind，那么就是买椟还珠了。

例子4：待续。。。。