java手机代码骂人_好的代码会说话-代码整洁之道

《代码整洁之道》总结

我们需要写出整洁的代码吗

我是个6年开发经验的java程序员，在我的职业生涯中，看到过不少让产生骂人冲动的代码，当然也写过让别人让别人想骂人的代码😀。我曾很多次想改进的我的代码风格，想让它们更易懂，更严谨，更整洁，更高效。但是终究还是写了很多烂代码。我总结了写烂代码的原因：

1、活多、时间紧。这可能是我们多数程序员写烂代码的直接原因，我们总抱怨需求紧时间少，功能实现就不错了，哪管代码的好赖，或许这只是一个接口，真正的原因是我们懒于思考。如何去改进代码风格。一个需求我们写代码的时间往往只占一小部分，就我个人而言，如果一个一天工作量的需求我写代码的时间往往不到2个小时。更多的时间一部分是搞清楚需求，另外一部分时间是和各种联调测试，当然还有同事随时来找我打断我的工作，重新开始写时就需要重新 理下写代码思路。如果是修改之前的功能那耗费最多时间的那就是阅读这个功能之前的代码。不管是调试代码还是阅读代码，代码的可读性至关重要,易读才是写代码高效的关键。多抽象出一个公用方法，变量名起的更贴切易懂写真的占用很多时间吗?好吧这些确实要占用你几分钟但当你调试或者修改时或许可以帮你省下几个小时.

2、老代码多人经手无力回天。这种情况我也遇到过很多，但是当我们放任这种情况不管，那这些代码只能越来越糟、越来越难以维护，最终变得不可维护。这种情况如果我们没有足够的信心去重构一些方法，那我们至少需要让 "让营地比你来时更干净"， 让代码签入时比签出时更干净。

3、我也想写出漂亮干净的代码，但是缺乏整体风格，想一出是一出，难以为继。这种情况也较为多见，什么叫整洁的代码，每个人理解不一样，一千个程序员就有一千种对好代码的理解。我的理解是写出最多人更易读懂的代码就是好代码。因为代码更多是被读的。不管是代码的作者自己还是别的程序员。

基于以上我认为整洁的代码应该是一个好程序员的基本素质。那么如何写出整洁的代码呢？以下是我在读完《代码整洁之道》然后基于我7年写代码的经验所做总结，以期能成为一个真正的好程序员。

java是有个@Auther注解~是的，作者，我们是代码的作者。我们要以作者心态自居，精心雕琢我们的代码，以期让我们的读者在读代码时能赏心悦目。

如何能写出好的代码

好的代码自己会说话-让命名更有意义

程序中通常需要命名的有三种：方法、变量、类。其中变量又分为局部变量和成员变量。首先我们看下下面这个变量

int d //过去的天数;

是不是很懵逼，要知道这个d表示的什么意思，你要通读这个变量的上下文才能知道。，即使你写了注释，当你写代码时或读代码时是不是经常要往上翻寻找这个d的注释。如果你起一个有含义的变量名，那读起来就大不一样了，在代码中直接就知道什么意思了。

int elapsedTimeInDays;

int daysSinceCreation;

int daysSinceModification;

int fileAgeInDays;

起上面这样的变量名是不是好多了，在代码中遇到直接就知道这个变量是什么意思，甚至不用写注释也知道这个变量的意思，不用去翻看程序的上下文或者找这个变量的注释。

再看下面的方法

public List getThem() {

List list1 = new ArrayList();

for (int[] x : theList)

if (x[0] == 4)

list1.add(x);

return list1;

}

看这样的方法，你的头顶是不是有很很多问号。倘若我们把方法名和变量名起的有意义一些呢如下：

public List getFlaggedCells() {

List flaggedCells = new ArrayList();

for (int[] cell : gameBoard)

if (cell[STATUS_VALUE] == FLAGGED)

flaggedCells.add(cell);

return flaggedCells;

}

这样是不是好多了，仅仅把变量名改成的有意义写，代码就变得已读了很多，此时还未改变代码的结构和嵌套。如果更进一步我们不用 int 数组表示单元格，而是另写一个类，这个类有个方法是否是Flagged的，遮掩住那个魔法变量则方法就能变成下面这样。是不是更易读了。

public List getFlaggedCells() {

List flaggedCells = new ArrayList();

for (Cell cell : gameBoard)

if (cell.isFlagged())

flaggedCells.add(cell);

return flaggedCells;

}

以上，我们只是简单了改变了代码的名称，代码的易读性大大提高。，代码本身就是最好的注释说明。

好的代码自己会说话-准确的命名、避免误导

如果我们命名一个数组的话，那便不要使用accountList的命名，这会给读者误导，误以为这个变量是个List类型，所以用accountGroup或者arrayOfAccount甚至直接用accounts都会比accountList更好。不准确命名的另外一个经常发生的例子是含有数字的变量名，这种经常发生我们要起一个变量名的时候发现这个变量重名了，我们经常会再新变量后面加个数字来区分和原来的变量。

public static void copyChars(char a1[], char a2[]) {

for (int i = 0; i < a1.length; i++) {

a2[i] = a1[i];

}

}

上面的代码如果改成下面的会不会好点

public static void copyChars(source a1[], destination a2[]) {

for (int i = 0; i < a1.length; i++) {

destination[i] = source[i];

}

}

命名还有一个经常发生不准确的命名的例子如下,这三个方法有什么区别呢，我们在使用时应该用哪个呢？这种命名区分毫无意义，调用者照样需要去看方法的实现或者注释来决定使用哪个方法。现代聪明的ide会把所有的方法列出来，然而你却不知道该使用那个方法。

getActiveAccount();

getActiveAccounts();

getActiveAccountInfo();

消除魔法数字如下一段代码，在代码中直接使用数字，通常读者不知道这个数字的含义，那当别人来读这段代码的时候就要去找这个数字的含义

Order order = new Order();

order.setStatus(0);

这段代码明显是给订单设置状态。但是0是什么状态，如果没有注释或文档的情况，需要找别的同事问呢，即使有注释和文档是不是也需要通过这段代码的上下文去找0的含义呢。如果我们把订单状态定义成一个enum或者常量:

Orderd order= new Order();

order.setStatus(ORDER_STATUS_PAY);

改进后的代码是不是很明显就知道这个地方把订单的状态设置为支付状态了。

好的代码自己会说话-类名和方法命名的更好实践

如何才能让我们的代码命名更清晰简短有效呢。下面是《代码代码简洁之道》一书中做的总结：

类名应该是名词或名词短语。如 Customer、WikiPage、Account 和 AddressParser。避免使用 Manager、Processor、Data 或 Info 这样的类名。类名不应当是动词。

方法名应当是动词或动词短语，如 postPayment、deletePage 或 save。属性访问器、修改器和断言应该根据其值命名，并依 Javabean 标准加上 get、set 和 is 前缀。

String name = employee.getName();

customer.setName("mike");

if (paycheck.isPosted())

重载构造器时，使用描述了参数的静态工厂方法名。例如，

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

通常好于

Complex fulcrumPoint = new Complex(23.0);

因为FromRealNumber描述了这个构造器和别的构造器的不同之处。

尽量给方法和类的命名都通俗易懂，不要为了耍宝起一些罕见的罕见的名字。毕竟代码是用来读的不是用来炫耀的。

每种概念都对应一个单词，并且一以贯之。如查询方法经常有get、query、find、select、fetch等词我们最好选一个词来对应查询这个概念

尽量避免用含有多个意思的词如add，既可以表示加法，又可以表示添加元素，有时会对读程序的人产生误导。

使用某种解决方案领域的专有名称，如果你使用了监听器，可以把类名后缀写成listener、如果使用访问者模式，可以用visitor作为类的后缀，如果使用了门面模式可用face作为后缀，这样在别的程序员读你的代码时就会有个全局的概念，知道你设计代码时的思路。更好的理解代码。

如果不能使用计算机解决方案领域的名词来命名，那就使用业务领域的名词来命名吧。至少，负责维护代码的程序员就能去请教领域专家了，优秀的程序员和设计师，其工作之一就是分离解决方案领域和业务领域的概念。与所涉问题领域更为贴近的代码，应当采用源自业务领域的名称。