编程小提示

一总则

1 编程最重要的是命名

         编程的所有注意事项中，我觉得没有比命名更重要的事情，这里命名的范围包括变量、函数、类等等。

 

2 程序员的职责是用编程语言去描述需求

         产品经理的职责是定义需求，唯一有权修改需求的就是产品经理了；而美工用图片来描述产品UI 的需求，架构设计师用拓扑图等来形式描述产品架构方面的需求，程序员是用编程语言来描述产品的业务逻辑。这就是说，美工、设计师、程序员都只是用自己的工具描述需求，而不是创造需求。

 

3 编程就是一个编程语言和业务逻辑结合的过程

         业务逻辑中有的概念，则必须反映到编程语言中，比如业务逻辑中的实体，反映到C++中就是一个类；反过来说，业务逻辑中没有的概念，则代码中也不应当出现，即代码不能凭空创造业务逻辑

 

4 编写代码的时候，功能实现是最先考虑的，但这只是代码的第一步，远远不应该仅仅只考虑功能实现

         我们要求的比功能实现要多得多，比如，代码的可读性。

 

5 训练和培养自己在代码规则下去编码的意识，代码规则有通用规则和与具体业务逻辑相结合的具体规则

         通用规则比如公司规定的编程规范（包含各种命名规范、代码版式规范等）。具体规则就是和业务逻辑相关的一些规则，比如UI类软件，可约定每个UI类的前缀用UI类型描述，如配置对话框的类取名为 DlgConfig 等

 

二命名规则

1 充分利用命名的前缀和后缀

         一般前缀用得多些，比如变量前缀多用来描述变量类型，类名前缀多用来描述类的类型，C开头是业务类，Dlg开头是对话框类等等。

         后缀一般用得很少，但也是一个可以利用和关注的点。

         这块的细则，建议通过代码规范的形式在公司或者项目组内强制执行。

 

2 成对使用单词

         典型的有：OPEN/CLOSE、CREATE/DESTROY、INITIALIZE/RELEASE、INIT/DEINIT、SAVE/LOAD、PUT/GET、SET/GET、SAVE/LOAD 等等。

 

3 只要有概念的地方，应当都有对应的规则来约束

         这个要做到很困难，但也是一个思路，我的观点是如果项目团队中有人提出了合适的规则来约束某一概念，则其他的同事应当尊重并采纳它的规则。

         比如全局变量是一个概念，用g_* 做前缀来描述，这条规则就是用来约束所有全局变量的，这样的规则有利于代码的可读性。

         再比如类中成员变量很多时候用 m_* 做前缀，也是一个很好的规则。

         这个规则更多应当体现在和业务逻辑结合的具体规则上，某个项目具体规则越多，则代表该项目模型抽象和代码可读性越好。

 

4 模块的接口定义建议是 C语言风格，而模块的实现则尽量用 C++ 语言

         如果接口定义用 C++ 语言，则那些用纯 C 实现的项目就无法使用了，虽然现在纯C 的项目已经极少了。

 

三类规则

1 做包含UI的软件产品开发时切记把UI和 业务逻辑分开

         这是很多初学VC开发的工程师最容易犯的错误，常常把UI 和业务逻辑放到一个窗口类中实现，然后随着功能需求的增加，该窗口类会逐步发育成一个所谓的超级类（偶尔我也叫它“上帝类”，意即无所不能）

 

2 理解和掌握类的四段式

         所谓四段式，指的是类的方法基本分为四类：OPEN、CLOSE、CONFIG 和 RUN。OPEN 就是初始化，CLOSE 就是关闭该类，CONFIG 指的是修改类运行时的某些方式，RUN 就是类的核心业务处理方法。

 

3 类是业务逻辑中的实体的映射，类的方法对应的是实体的动作

         根绝这个规则，于是类的命名一般都是名词，而类的方法（即函数），基本都是动词，或者动宾结构的词组

 

4 建议类的数据全部用 private 或者 protected 修饰，不要用 public

         这是所谓数据封装原则

 

5 类的内部数据最好也是业务逻辑中实体的映射，本质上可以认为类由它的数据所组成

         按照这个组成原则，人这个类的内部数据大概不外乎头、脚、手等等东西（或实体）。这里要强调的是那些不该放入类中的实体，比如，人呼吸空气，人这个类内部很多数据都可能会和空气打交道，但是，把空气作为人这个类的内部数据放入类中，我觉得是不合适的。但是在现实的很多类的设计实践中，程序员往往会犯这个错误。

 

6 类的数据和方法的定义，要有层次概念

         同一个层次、等级的东西放到一起，比如 CPerson 这个类，里面放 Chand、CFoot、CHead 等是合适的，把手指头、眼睛等都放到 CPerson 中则是不合适的。现实的类设计和实现时，类数据的层次性常常不会这么明显，这叫要求我们程序员在这条规则上更加重视。

 

四编码规则

1 不推荐用引用

         引用可以用指针代替，代码的可读性会更好

 

2 用 0 表示返回值正确，还是用TRUE( 1 ) 表示正确，这是个问题

         C语言的风格是 0 表示正确，-1 -2 -3 ….  都表示错误，或者说是表示各种错误。

         而 C++ 的风格是 TRUE=1 表示正确， FALSE=0表示假，即错误，要标识错误号的话，没 C 语言风格方便。

         两种风格都可以，最重要一个项目里面，需要明确下来采用哪种风格，而不建议混用。

 

3 判断返回值应当用 if(A==XX_OK) ，而非 if (A!=XX_ERROR)

         具体原因不赘述