乐趣区

关于程序员:为什么我们不应该写长方法

初学者在学习了语法和一堆的 API 之后,就会尝试本人写一些具备残缺性能的程序。这个过程当中很容易养成写一个上百行甚至几百行的办法的习惯。总的来说,这是思维当中短少形象、设计和封装的体现。随着编程教训的丰盛,总会有克服的一天。

但如果想尽早克服这种状况,像业余程序员那样去思考,那么要多读一些 设计 代码可读性 方面的书。业界有很多经典的书,比方《设计模式》、《重构》、《代码整洁之道》、《实现模式》等。我强烈推荐这四本,因为我集体从中受益匪浅,感觉它们都是必读的。

当一个屏幕装不下你的办法体时,就要当心了。

长办法的害处十分多,次要体现在以下几个方面:

一、长办法中会蕴含特地多的变量。

长的办法逻辑多,变量天然也多。太多的变量常常会随同上面的问题:

1、命名艰难。当你要定义 4 个元素类型为 UnfinishedCustomOrder 的 List,以及 4 个元素类型为 FinishedCustomOrder 的 List 时,这些变量的名字会十分长,而且眼神不好的话,前面还容易用错,呈现 bug。

2、重 (chong) 用变量。 初学者对变量的命名存在随意性,同时应用变量也存在随意性。比方定义一个 boolean flag 变量,在这段逻辑外面用过一遍,而后在那段逻辑外面再用一遍。

3、反复的变量。 一个办法长到肯定水平后,常常会呈现写到前面忘了后面的状况。于是呈现比如说,又从新去数据库查问之前曾经查过一次的内容的状况。这种景象特地容易呈现在重复批改过屡次,而且每次都是不同的人来改的代码中。

4、改了变量内容然而忘了。 比方上面这种:

public void processAllOrders() {
    List allOrders = ...;  // 查问所有订单
    ...
    // 排除掉已实现订单。留神这条语句甚至可能被委托到
    // 另一个办法执行,本办法中齐全看不到。allOrders.removeAll(finishedOrders); 
    ...
    ... // 两百行代码后
    ...
    ...
    ...
    // 此时另一个程序员接手实现需求变更。他只关注这部分要改的,// 仅看变量名就认为 allOrders 仍旧蕴含所有订单,于是出错
    allOrders.forEach(order -> {...});
    ...
}

这属于重大违反编码准则的状况。有人说,是不是接手的这个程序员浏览代码不认真啊?请留神,浏览代码自身是十分耗费心智的。读代码不是读小说,要严丝合缝的了解代码的行为。如果代码可读性很差,那么了解出错的机率天然也会大,更别说下面的例子中,变量名存在误导性,这能怪阅读者吗?

二、长办法会有很多进口。

一个长办法的执行过程实际上是分几个阶段实现的,每个阶段可能有本人的近程调用、数据校验和抛出异样,这会导致长办法中有很多进口。一个办法有多个进口,大多数状况下是不好的编程习惯,次要体现在:

1、调试断点会呈现不确定性。 比方你在某行打了个断点,但调试的时候发现没有执行,因为办法在这之前就通过某个进口完结了。重复尝试寻找断点升高了开发效率。

2、重复构建返回值。 如果办法是有返回值的,那么多个进口的返回值当然是不一样的,它们的后面必然会呈现雷同的构建这些返回值的过程。一旦这个过程须要改变,那么脱漏某处就意味着 BUG。

3、有的 return 语句写在层层缩进当中,会给浏览带来艰难。 因为当你读到这里时,会发现脑海中构建的一层层的逻辑,到了这里忽然被彻底中断了,在某个场景下,办法在这里完结。于是你必须牢记,前面的代码中的所有逻辑都要排除这个场景。这样的完结若再来个两三次,恐怕能把你逼疯。

我之前说的是大多数状况。那么剩下的状况是指什么呢?次要是校验办法,比方:

public boolean validate(Order order) {if (order == null) {return false;}
  if (order.isCancelled()) {return false;}
  ...
  return true;
}

此类办法有多个进口我感觉是能够承受的。

三、浏览长办法十分劳神。

咱们浏览办法时,会在脑海中构建每个参数和变量,了解它们的演变过程。这个时候每多一个变量,都是减少了一分脑力累赘。要晓得,人与人之间的脑力承受能力是不同的,就算同一个人,在不同的精神状态下的承受能力也有差异。所以,如果一个软件产品或我的项目,想要在整个生命周期中缩小出错的可能,那么就有必要晋升代码 可读性 ,换句话说,就是 缩小浏览代码的脑力累赘。代码可读性是危险管制的一部分,长办法为我的项目减少了危险。

如何克服

下面说的就是一个办法太长会带来哪些问题。要克服的话,首先是看我最开始举荐的那几本书,其次是造就本人的抽象思维,从具体的性能中提取出多个档次的形象逻辑,将性能的实现拆分到不同的形象层。

退出移动版