编程最佳实践

1、定义变量时就初始化值

尽管很多代码检查工具，强烈建议去掉初始化无意义的值，但是，给一个初始值能避免很多程序异常。永远知道：代码检查工具给你的只是普适意义下的“建议”，而非“强制修改”的必要条件。

这里有好多公司，生搬硬套，必须按照代码检查工具来修改，简直是“愚蠢之级”！

2、意义改变就定义多个变量，不要反复使用同一变量，除非意义“完全相同”

有时候，复用同一个变量会：

（1）增加程序调试难度，造成混淆（需要反复跟踪代码知道“就在这时”，值是什么）

（2）容易赋值错误，导致逻辑错误

（3）增加后续迭代成本（不分析之前有多少个地方用同一变量，根本不能轻易使用）

3、谨慎使用异常

除非有合理的异常捕捉、处理思考，否则程序会莫名的被抛出异常，让用户感到困惑；或者被“吃掉”，掩盖了程序本身的问题。

4、严格控制变量的类型

在最开始定义Model的阶段就要考虑好一个变量的类型，究竟应该是什么，因为不同类型转换的原始方法有很多坑。

笔者也遇到过，同一个业务含义的字段，但是需要定义两种类型的情况（一个是浮点数、一个是字符串型的），这种如果定义成一个类型，业务逻辑就需要不同使用场景下来回转换，而开发语言的转换方法“往往是特别容易报错的”，比如：null值时、“”值时。

5、表字段的设计最好不要用null作为默认值

6、控制字段长度为最佳长度，不要过度让字段很长。因为存储、IO都耗费性能

7、避免过多的表，例如某碟的ERP，底层一万多张表，无论是重构还是拓展都是一场“论持久战”，哪怕你仅仅想要开发的是第一个最精简的库存系统。

多建立“综合性强”的表，合并能够整合的表，不要因为A整合B之后会有B表用不到的字段就单独建立一张B表。

8、避免过长的变量名

有的公司规定，无论变量、方法还是类名都要符合实际意义，在很多业务场景下，往往需要数个单词来组合，但是过长的文件名可读性是非常差的，尤其是三个方法的的单词组合都接近的时候，区分方法名，简直就是一个“识字游戏”，差一个字母就用错了。

9、合理利用罗马数字

罗马数字的辨识度永远比单词要好的多得多，但请不要使用过短的字母加罗马数字的组合，例如：a1、a2、m1、m2。可以是addr1、addr2

另外罗马数字也可以适度减少1和0，因为1像字母l，0像字母O

10、减少下划线等特殊符号的使用

例如：user_name，建议改为username，因为切换特殊字符尽管对于大多数成员来说是轻而易举的事情，但是如非必要，尽量只使用字母+数字的组合。

11、避免使用所有开发语言、数据库的关键字

例如：order、desc、cast、string。