如何写出优秀的代码

写了太多屎一样的代码，终于不臭了！

更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』

1.第一坨屎-变量

为了不让下任『接盘侠』看到代码骂娘，我劝你善良。请不要使用如下方式命名变量：

1.拼音命名（不会英文就去下载个某道词典，翻译一下嘛。name 总比 mingzi 好辨认吧？字数还少，还能国际通用）

2.使用简单字母命名（a/b等等，别说其他人，过两天自己都不晓得写了个什么鬼）

3.异想天开（不要随便拍脑袋起名，要做到见名知义。总不能一个 id 的列表，你叫个 item 吧？xxx_id_list 稍微强一些吧？）

4.不要命名冲突（最起码在一个函数内，不能重复。 project 既是生产项目又是测试项目？变量不断被覆盖，奇奇怪怪的 bug 就够你喝一壶的了）

这种病的病根儿一般是词汇量匮乏，治疗建议某道翻译。

5.查询数据库时，变量与字段名、模型类或者表名不一致（查的 Product 就不要叫 Mobiles；查的 name ，就不要叫 leader ）

2.第二坨屎-注释

为了第二天代码还认识你，请你添加注释。

1.一定要添加注释，最起码重要的逻辑部分覆盖到。

2.注释要清晰、易懂、简单明了。

3.注释不是流水账，不是每一行代码的解释，而是某一块逻辑的说明。

4.对于复杂的数据结构请举例说明。

5.每个函数的说明文档起码要有。

3.第三坨屎-嵌套

1.不要里三层外三层的 if-else，逻辑判断可以有，但是一定有更加简明的表示方法。嵌套的层级太多，不仅难理解，还影响美观。

2.简单的一层 if-else ，有时三元运算符会更加方便。

3.若想你的程序执行效率高一些，就不要循环套循环。

4.无论何时何地都不要在循环里面有查询数据库的语句。也许一次访问，只需要查询几次数据库，但是用户量大时，能把你数据库搞瘫。多使用一些 bulk_create 或者 bulk_update 等等类似的批量操作方法，一次访问远比多次访问数据库效率高。

4.第四坨屎-逻辑

1.请将复杂的逻辑单独抽出来做成函数或者类，不要让你的接口内部过于复杂。否则即使有注释，也太晦涩难懂。

将复杂逻辑抽调后，不光能被其他地方调用，还能使你的接口清晰明了。

2.实现一个功能，肯定不止一种方法，要不断的去优化，去寻找一条最快最简单的路径。

当然优化的前提是存在，即使用笨办法也得先实现再说。

5.第五坨屎-校验

1.一定要添加必要的校验操作！一定要添加必要的校验操作！一定要添加必要的校验操作！重要的事情说三遍，想要保证程序的健壮性，永远不要相信用户的任何操作！（用户不是开发人员，一定会做出你想不到的操作。为了保证程序安全、数据安全，请添加校验）

2.常用的校验有：为空校验、长度校验、规则校验、常识性校验（最起码上限不能低于下限）、业务校验、边界情况校验等。

6.第六坨屎-单元测试

1.自动化远比人工可靠。

不是说人工偷懒，而是重复的点点点难免会有遗漏的情况。添加单元测试，就要可靠的多。

2.单元测试并不是负担，当你重构代码时，你会发现它的重要作用！

有单元测试做保障，测试通过就代表重构成功。不需要重复界面点点点，太浪费时间。当然前提是：你的单元测试是可靠的。

3.重要的方法、逻辑，单元测试一定要覆盖到，它会保证你的程序安全上线！

4.code_review 只能是看规范，看逻辑，肉眼能核对运行结果吗？提交代码先跑一遍单元测试，是否可靠的多？

这就体现出来自动化测试的好处了，最简单的方法，在 GitLab 上集成单元测试，这样提交代码后自动运行单元测试，不通过肯定不会合并到 master 分支，保证线上环境安全。

7.第七坨屎-重用

1.将公共的代码抽调出来，做成公共模块、通用组件。减少程序代码量，让程序起飞。

2.重用的优点不光是省代码这么简单，如果相同的代码这也有，那也有，出错怎么办？改几遍？便于维护

3.将常用的数字抽出一个常数文件，其他地方调用变量的形式使用，这样维护一个常数文件比维护分散在各个角落的代码要好的多。

更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』