这个题目把我自己都看傻了,因为仔细想想,这不是一个命题,是对代码的思考,对细节的推敲和打磨。写好代码是一门学问,还是一种修行。 以前是公众号(JackieZheng)和博客同步更新,尤其是技术类文章。但是最近在公众号上写的比较多,因为在那我可以想写多少写多少,随时随地记录下自己的心得,还有勉励自己的鸡汤或是毒鸡汤。 以后应该会阶段性把公众号的文章总结出来,写成一篇博客,想了想,这样比较符合这两个平台的特性。
函数贵在短小。
getData(...)
,还有一个叫做getPersonByName(...)
,显然后者强势碾压前者,起码我是这么认为的。这么写还有一个附加好处,就是省去了注释,因为方法名就是注释。
函数的目的就是为了告诉你它干了什么事,准确的说,它干了具体哪一件事。在设计模式的指导思想里面是有单一职责原则,对于函数也是一样。别指望一个函数能把所有的活都包了,那样大家都很累。比如public PersonResult doSomething(String name, boolean isMarked, Person person) {
String[] names = name.split(",");
for(String name : names) {
//do some convert or others operations
}
if(isMarked) {
PersonResult personResult = new PersonResult();
personResult.setAge(person.getAget());
// ...
}
return personResult;
}
例子是刚刚想的,当然你可以写一个很长的全能doSomething
函数,但是读的人真的累。如果可以的话,这样是不是更好点
稍稍对比下,短小真的不是坏事,它能保持函数的内容在同一抽象层上,看着也舒服。
public double getTotalSalaray() {
double baseSalaray = getBaseSalary();
//...
double salaryPart1 = 100;
double salaryPart2 = 200;
double salaryPart3 = 300;
double performanceSalary = salaryPart1 + salaryPart2 + ... + salaryPartN;N
return baseSalary + performanceSalary;
}
这个函数很单纯,真的只做了一件事,就是得到工资总额,包括基本工资和绩效工资。当我们看完第一行代码的时候,我们觉得赏心悦目,很好理解,如果你比较关系基本工资的细节,大可进入getBaseSalary()
方面里面一看究竟,可是在后面的绩效工资部分,就显得有些画风不对,我们不需要着这样的细节处理,我们更渴望与获取基本工资一样的抽象即可,好比这样
public double getTotalSalaray() {
double baseSalaray = getBaseSalary();
//...
double performanceSalaray = getPerformanceSalary();
return baseSalary + performanceSalary;
}
有多少码农曾经一直被告诫要多些注释,写好注释,起码我之前是这样的被叮嘱的。但是看完《代码整洁之道》,发现注释不是什么好东西,起码没有我们想的那么好。
public void getData(boolean isAdmin) {
// if isAdmin is true, get isGroup, if isGroup is true then doSomething
if(!isAdmin) {
boolean isGroup = PermissionUtil.getIsGroup();
if(isGroup) {
...
}
}
}
因为有很多判断,相信你应该会看一眼注释来帮助自己更好的理解这段代码,但是仔细一推敲,发现代码中的逻辑应该是isAdmin
为false
的时候,才会去获取isGroup
的值,而非像注释中提到为true
的时候。
/**
*get Person entity by id
*/
...
帮助澄清信息,比如
//example: www.test.childtest.com/v5/666
...domain + childDomain + version + id...
警示信息,对于一些代码的使用有些特殊场景要求,可以通过注释标示出来。 TODO 这个大家应该会经常使用吧,用来标记一些我们即将要实现的功能或者带扩展的功能。