代码整洁一

什么是代码整洁

    今天来说说“代码整洁”，这是个永恒的话题，自从第一行代码被写出来后，优秀的程序员们就不停地通过各种方法、方式和工具来使自己的代码看来整洁美观。那为什么我们要做代码整洁？不管你做过几年编程，你一定被某个傻缺的糟糕代码绊倒过气的找不到北；同时自己也肯定写过这种代码把别人坑的不要不要的，让人指着后脊梁骨暗骂一通。*讲过批评与自我批评，人总是在自我检讨中成长，所以就先来让我们先看看代码混乱主要的几种原因（各种案例在下一章列出）：

• l  混乱的格式排版,各种风格写法
• l  文不对意的表达式（变量、函数、属性等等）
• l  毫无注释的白板代码；
• l  面条式函数，职责功能混杂在一起；
• l  逻辑混乱的代码；
• l  僵尸代码，无效代码，无数个参数的函数；
• l  ....（希望大家补充）

    如果你一直都是写出上面所描述的混乱不堪的代码，不仅得不到同事的尊重，自己你的编码水平也不会随着时间推移而提升，更容易成为n年工作经验，混乱不堪的代码更是将项目推向难以维护的境地。所以从个人角度上说，整洁好看的代码不仅是你技术水平体现更能让你赢得大家的尊重；从项目角度上说，整洁优秀的代码是产品可维护性基石，整洁有序的代码是任何产品失控之前的第一道防线；所以优秀整洁的代码在公在私都极为重要，鉴于以上原因我将代码整洁作为我们分享会第一课，就是趁在座各位都还处于代码婴儿阶段，让大家养好习惯、打好基础、培养好自己的代码思想力为你们日后成为代码大师打下最坚实的基础。

最后，将美国童子军的一条简单军规应用到我们的专业领域：“让营地比你来的时候更干净。”--《代码整洁之道》

怎么样做才是代码整洁

灌了这么多心灵鸡汤，那么我们怎么做好代码整洁，在我看来有两个方面：

一、调整心态

你是否在写代码时，是否有下面心理状态：

•  “进度来不及，这个后面再优化吧，先把功能实现了”，若干年后，你会看到这段代码依然活着，注释依然还在；
• “重构太麻烦了，这段代码还是copy一份，到我自己文件里面去吧，重复就重复吧”，若干年后，你会看到到处都是一模一样的代码；
• “这么垃圾代码，不是我写的我才懒的改， 反正它运行的就行了”，总有一天你会绕不开它被它坑一次；
•  “我英文不行，变量名随便下，aabb，文件名随便定下”，若干年后，你会发现自己都找不到这个文件；

上述原因，跟任何技术水平有关吗？

   无关，全部都是心态上的问题，所以提高代码整洁第一步就是需要提高自我责任心，不断的心理暗示告诉自己需要对自己的代码负责，如何写的更好看一些，如何让别人更容易读懂一些，需要你有处女座般的洁癖来打造自己的代码。

二、硬性技能

1. 有意义的命名

代码中随处可见命名。我们给变量、函数、参数、类和文件命名。我们写代码30%都在命名， 选个好名字要花时间，但省下来的时间比花掉的多。而且一旦发现有更好的名称，就替换掉旧的。这么做，读你代码的人（包括你自己）都会更开心？下文旧列出几条简单规则（本文不是讨论具体代码规范，因为有太多太多内容可以谈，所以将以概念为主）。

1.1 名副其实的名称

如下图一，简洁且格式代码也符合.net标准。但是你能知道它做什么吗？

 

主要有3个问题：一、函数名不知道做什么；二、函数参数不知道传入什么、三、使用字面量。归结起来，按专业的说法：简洁度达标，但是模糊度太高，无法见文知意。

我们先看调整后的代码格式

    这里，我们做了几个修改，可以很明显看到效果：

1. 变量名，不要再使用list，使用具体作用含义；
2. 使用“魔法数”，不使用“字面量”，将“4”使用变量代替

1.2 一致的拼写，避免误导

当你在设计api,编写业务层代码时，没有绝对的标准，但是请与旧代码保持一致性。举个例子：

正例：

getorganbyorgid(string orgid)

getorganbyparentid(string parentid)

getorganbyorgentity(organ entity);

反例：

  getorgandata(string orgid)

  loadorganbyorglist(organ entity)

  loadorganuseparentid(string parentid)

现代化的ide的智能感知已经非常先进，很多程序员已经不看接口文档，如果一致的拼写，在ide智能感知了，就非常方便开发人员调用； 

1.3 做有意义的区分

    1.3.1 不要以数字系列命名，例如a1,a2…an。如下反例：

public datatable getcostlistbyuserdate(datetime date1,datetime date2);

但是这样，完全无法体现出来参数的作用及作者意图，正例：

public datatable getcostlistbyuserdate(datetime starttime,datetime endtime);

    1.3.2 不要添加废话修饰

        不要加上,info ,data ,the 这些废话定词

        例如： accountinfo、accountdata与 account 。其实代表一样的含义；

        再比如，

1.4 使用可搜索的名称

    同1.1中的魔法术,这点是最容易改进的，搜索“4”容易还是搜索”check_flag”容易？

1.5 避免使用编码，前缀

    在远古时代，因为ide还不流行。需要在变量名前，加前缀；例如 b_ 代表byte.i_ 代码表int类型；但是现在ide已经非常流行了，无需再加这些前缀；

1.6 类名方法名

    类名、变量名应该是名词短语,例如： account,page,customer等。

    方法名，应该是动词短语，例如：getaccount,downloadpage

1.7改善措施：

l  学习英语（我老大上市公司研发部总监，依然每天朋友圈打卡学习英语，开始学习吧，没人笑你！这是你日后职场上的最重要武器之一 ）

l  常用词列表（会随着部门代码规范一起发布）

2. 一致性的格式

2.1 团队规则

每个coder都有自己喜欢的格式规则，但是如果在一个团队中，就应该团队说了算。而不是让它显得有一大票意见相做的个人所写成。

我们的措施：.net代码规范（自定义 + stylecop.analyzers )

javascript：代码规范（需要大家群策群力）

2.2 垂直格式

向报纸学习，源文件也要像报纸文章那样。名称应当简单而且一目了然。源文件最顶部应该给出高层次的概念和算法。细节应该往下渐次展开，直到源文件中的最底层函数和细节。

例如：

.net中，类中的全局变量，私有变量，常量等等，均放在类中最顶部

函数方法，public , protect private，按顺序摆放。

javascript中，全局变量，私有变量，常量等等，均放在类中最顶部

2.3 横向格式

  我刚工作时，当时的代码规范是横向建议一行最多不超过80个字符。随着近年显示器越来越大，一行大家都默认不超过120个字符原则，但是不管什么样显示，我们保持无横向滚动条原则。