最近有机会看号称是公司最核心的代码， 因为这个代码以前一直是美国那边保密的， 这么重要的代码会是啥样子？
真正拿到手大致看了一下后却挺失望的，因为该代码风格基本上是我刚毕业时的C++风格----带类的C，单从代码上看写的挺滥，里面没啥设计模式， 也没有用模板， 代码里面甚至一个函数可以写上近千行。
这么重要的代码， 竟然是这种风格， 挺郁闷，由此思考好的C++程序应该是什么风格？
C++因为本身支持多种范型设计(面向过程， 基于对象，面向对象，普通泛型，模板元编程等)， 使得C++的程序风格和其他语言相比更加多种多样。所以有人评价C++像一把瑞士军刀， 什么功能都有， 你想拿它当什么刀使，它就能成为什么刀， 所以它很强大，强大的同时也意味着复杂。其他语言，比如Java/C#主要只支持面向对象，这样他们的风格就很统一， 无论是标准库，框架还是应用，都是以对象，接口和模式为主导。 但是C++程序就不一样了， 可以说C++程序风格没有固定的标准， 每个人根据他的经历和使用的框架，会有完全不一样的风格， 网上别人总结了一些C++程序风格：
1. 经典C++流：类是核心，例程多用C Runtime的，很少用模版，一般是正统教育的结果。
2. 古典C流：基本上当C用，偶尔用用对象，不使用异常，喜欢怀旧。
3. MFC流：秉承MFC的风格，主要使用MFC/ATL对象和Win32 API，不喜欢STL，用很多的宏把IDE的语法提示模块折磨到崩溃。
4. Portable流：以C Runtime和STL为主要工具，使用类和模版，不跨平台毋宁死。
5. Functional流：以模版和STL为主要武器，大量使用函数式语言的设计方法，并号称这才是真正的C++。
6. Win32流：多使用全局函数，偏爱Win32 API，但不排斥C Runtime，通常喜欢轻量级的程序，所以身材也比较苗条。
7. Java流：全面使用Java的风格，不能容许任何全局成员，但允许使用STL的集合类，写很多叫Factory的类。
8. COM流：喜欢AddRef()和Release()，大量使用接口，隐藏一切可以隐藏的东西，诵经的时候要把上帝替换成COM。
9. 戒律流：追求完美的C++程序，计较每一个const和throw()，极力避免不安全的cast，随身一定要带一本ISO C++手册。
10. 混沌流：其程序无常形，无恒道，变幻莫测，吾不知其名。
上面确实总结了我们常见的一些C++程序风格，相信大部分C++程序员都可以再里面找到自己曾经或现在的影子。另外每个人C++程序风格不是一成不变的，随着他的项目经历会不断的变化。比如一般人刚毕业时的风格都是带类的C，代码风格偏向面向过程； 后来随着对面向对象的深入， 慢慢地会使用模式和接口来设计，此时代码风格偏向面向对象； 再后面可能会深入STL和泛型，甚至模板元编程， 此时代码风格使用模板泛型； 最后有些人可能会觉得过度的关注面向对象的设计模式和模板的泛型设计， 会让人偏离对要解决的问题本身的关注， 最后他的风格又回到了原始的C或是刚毕业时带类的C的风格。
从上面可以看到，对于C++程序风格，我们很难定出一个比较统一的标准，但是我想我们可以根据我们要解决的问题不同而使用不同的风格。下面是我个人的一些看法：
（1）C++底层语言基础库（STL, Boost）以泛型为主导， 以高效通用为设计原则， 这方面我想大家已经达成共识。
（2）C++应用基础库和框架以面向对象和泛型为主导。基础框架一般对扩展性和性能都有一定要求，对于框架一般我们是大量实践经验的总结 ，所以基本上已经知道它的所有可变情况， 所以理论上我们可以通过模板参数的Traits和Policy来分离所有可能的情况，框架本身也有一定的复杂性，需要面向对象来封装和解耦， ATL是这方面作为COM组件开发基础库的成功例子。基础框架以高效,专用和扩展性为设计原则。
（3）C++应用层以面向对象为主导。应用层逻辑是多变的， 理论上你也可以采用模板参数的方式来应对变化， 但是应用层的变化非常复杂， 很多事不可预测的， 所以你不可能以模板参数的方式预测到所有可能的情况。另外C++现在还没有对泛型Concepts的描述机制， 导致模板代码比较难懂。在多变的应用层大量采用模板显然不是一个好的选择。 另外模板在应用层的大量使用也没有比较成熟的经验， 而面向对象和模式已经是非常成熟。应用层以灵活应对变化为设计原则。
（4）C++模块（DLL）间的交互则以C方式API或是仿COM（Interface+Factory）为主导， 模块接口和交互以简洁和二进制兼容为设计原则。
总之， 我们应该灵活应用C++各种风格和范型的特点， 采用 ”多范型“ 程序设计的思路来解决问题， 而不是采用单一风格。
最后，回到我最初的公司核心代码， 该代码是用来解决某个特定问题， 显然与通用性和可扩展性关系都不大， 也就不需要所谓的模式和模板了， 实际上你越往操作系统底层， 你离这些东西就越远， 所以Linux之父才会给C++差评。
真正拿到手大致看了一下后却挺失望的，因为该代码风格基本上是我刚毕业时的C++风格----带类的C，单从代码上看写的挺滥，里面没啥设计模式， 也没有用模板， 代码里面甚至一个函数可以写上近千行。
这么重要的代码， 竟然是这种风格， 挺郁闷，由此思考好的C++程序应该是什么风格？
C++因为本身支持多种范型设计(面向过程， 基于对象，面向对象，普通泛型，模板元编程等)， 使得C++的程序风格和其他语言相比更加多种多样。所以有人评价C++像一把瑞士军刀， 什么功能都有， 你想拿它当什么刀使，它就能成为什么刀， 所以它很强大，强大的同时也意味着复杂。其他语言，比如Java/C#主要只支持面向对象，这样他们的风格就很统一， 无论是标准库，框架还是应用，都是以对象，接口和模式为主导。 但是C++程序就不一样了， 可以说C++程序风格没有固定的标准， 每个人根据他的经历和使用的框架，会有完全不一样的风格， 网上别人总结了一些C++程序风格：
1. 经典C++流：类是核心，例程多用C Runtime的，很少用模版，一般是正统教育的结果。
2. 古典C流：基本上当C用，偶尔用用对象，不使用异常，喜欢怀旧。
3. MFC流：秉承MFC的风格，主要使用MFC/ATL对象和Win32 API，不喜欢STL，用很多的宏把IDE的语法提示模块折磨到崩溃。
4. Portable流：以C Runtime和STL为主要工具，使用类和模版，不跨平台毋宁死。
5. Functional流：以模版和STL为主要武器，大量使用函数式语言的设计方法，并号称这才是真正的C++。
6. Win32流：多使用全局函数，偏爱Win32 API，但不排斥C Runtime，通常喜欢轻量级的程序，所以身材也比较苗条。
7. Java流：全面使用Java的风格，不能容许任何全局成员，但允许使用STL的集合类，写很多叫Factory的类。
8. COM流：喜欢AddRef()和Release()，大量使用接口，隐藏一切可以隐藏的东西，诵经的时候要把上帝替换成COM。
9. 戒律流：追求完美的C++程序，计较每一个const和throw()，极力避免不安全的cast，随身一定要带一本ISO C++手册。
10. 混沌流：其程序无常形，无恒道，变幻莫测，吾不知其名。
上面确实总结了我们常见的一些C++程序风格，相信大部分C++程序员都可以再里面找到自己曾经或现在的影子。另外每个人C++程序风格不是一成不变的，随着他的项目经历会不断的变化。比如一般人刚毕业时的风格都是带类的C，代码风格偏向面向过程； 后来随着对面向对象的深入， 慢慢地会使用模式和接口来设计，此时代码风格偏向面向对象； 再后面可能会深入STL和泛型，甚至模板元编程， 此时代码风格使用模板泛型； 最后有些人可能会觉得过度的关注面向对象的设计模式和模板的泛型设计， 会让人偏离对要解决的问题本身的关注， 最后他的风格又回到了原始的C或是刚毕业时带类的C的风格。
从上面可以看到，对于C++程序风格，我们很难定出一个比较统一的标准，但是我想我们可以根据我们要解决的问题不同而使用不同的风格。下面是我个人的一些看法：
（1）C++底层语言基础库（STL, Boost）以泛型为主导， 以高效通用为设计原则， 这方面我想大家已经达成共识。
（2）C++应用基础库和框架以面向对象和泛型为主导。基础框架一般对扩展性和性能都有一定要求，对于框架一般我们是大量实践经验的总结 ，所以基本上已经知道它的所有可变情况， 所以理论上我们可以通过模板参数的Traits和Policy来分离所有可能的情况，框架本身也有一定的复杂性，需要面向对象来封装和解耦， ATL是这方面作为COM组件开发基础库的成功例子。基础框架以高效,专用和扩展性为设计原则。
（3）C++应用层以面向对象为主导。应用层逻辑是多变的， 理论上你也可以采用模板参数的方式来应对变化， 但是应用层的变化非常复杂， 很多事不可预测的， 所以你不可能以模板参数的方式预测到所有可能的情况。另外C++现在还没有对泛型Concepts的描述机制， 导致模板代码比较难懂。在多变的应用层大量采用模板显然不是一个好的选择。 另外模板在应用层的大量使用也没有比较成熟的经验， 而面向对象和模式已经是非常成熟。应用层以灵活应对变化为设计原则。
（4）C++模块（DLL）间的交互则以C方式API或是仿COM（Interface+Factory）为主导， 模块接口和交互以简洁和二进制兼容为设计原则。
总之， 我们应该灵活应用C++各种风格和范型的特点， 采用 ”多范型“ 程序设计的思路来解决问题， 而不是采用单一风格。
最后，回到我最初的公司核心代码， 该代码是用来解决某个特定问题， 显然与通用性和可扩展性关系都不大， 也就不需要所谓的模式和模板了， 实际上你越往操作系统底层， 你离这些东西就越远， 所以Linux之父才会给C++差评。
