创意电子

标题: 看了同事的代码，我不由得写了这份代码指南 [打印本页]
作者: Python部落    时间: 2020-5-14 11:24
标题: 看了同事的代码，我不由得写了这份代码指南
作者：xybaby
链接：https://www.cnblogs.com/xybaby/p/11335829.html
写出整洁的代码，是每个程序员的寻求。《clean code》指出，要想写出好的代码，首先得知道什么是肮脏代码、什么是整洁代码；然后通过大量的刻意练习，才能真正写出整洁的代码。
WTF/min是衡量代码质量的唯一标准，Uncle Bob在书中称糟糕的代码为沼泽（wading），这只突出了我们是糟糕代码的受害者。国内有一个更适合的词汇：屎山，虽然不是很文雅但是更加客观，程序员既是受害者也是加害者。
对于什么是整洁的代码，书中给出了大师们的总结：
其中，我最喜欢的是表达力（Expressiveness）这个描述，这个词好像道出了好代码的真谛：用简朴直接的方式描绘出代码的功能，不多也不少。

命名的艺术

坦白的说，命名是一件困难的事情，要想出一个恰到好处的命名必要一番功夫，尤其我们的母语还不是编程语言所通用的英语。不过这一切都是值得了，好的命名让你的代码更直观，更有表达力。
好的命名应该有下面的特征：
名副其实
好的变量名告诉你：是什么东西，为什么存在，该怎么使用
如果必要通过注释来解释变量，那么就先得不那么名副其实了。
下面是书中的一个示例代码，展示了命名对代码质量的提升
# bad code
def getItem(theList):
ret =
for x in theList:
if x[0] == 4:
ret.append(x)
return ret

# good code
def getFlaggedCell(gameBoard):
'''扫雷游戏，flagged： 翻转'''
flaggedCells =
for cell in gameBoard:
if cell.IsFlagged:
flaggedCells.append(cell)
return flaggedCells避免误导
这里不得不吐槽前两天才看到的一份代码，居然使用了 l 作为变量名；而且，user居然是一个list（单复数都没学好！！）
有意义的区分
代码是写给机器执行，也是给人阅读的，所以概念一定要有区分度
# bad
def copy(a_list, b_list):
pass
# good
def copy(source, destination):
pass使用读的出来的单词
如果名称读不出来，那么讨论的时候就会像个傻鸟
使用方便搜刮的命名
名字长短应与其作用域巨细相对应
避免头脑映射
比如在代码中写一个temp，那么读者就得每次看到这个单词的时候翻译成其真正的意义

注释

有表达力的代码是无需注释的。
The proper use of comments is to compensate for our failure to express ourself in code.
注释的适当作用在于补充我们用代码表达意图时遇到的失败，这听起来让人沮丧，但事实确实云云。The truth is in the code, 注释只是二手信息，二者的差别步或者不等价是注释的最大问题。
书中给出了一个非常形象的例子来展示：用代码来阐述，而非注释
bad
// check to see if the employee is eligible for full benefit
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
good
if (employee.isEligibleForFullBenefits)因此，当想要添加注释的时候，可以想想是否可以通过修改命名，或者修改函数（代码）的抽象层级来展示代码的意图。
当然，也不能因噎废食，书中指出了以下一些情况属于好的注释
其中个人最赞同的是第2点和第5点，做什么很容易通过命名表达，但为什么要这么做则并不直观，特别涉及到专业知识、算法的时候。别的，有些第一感觉“不那么优雅”的代码，也许有其特殊愿意，那么这样的代码就应该加上注释，阐明为什么要这样，比如为了提升关键路径的性能，可能会捐躯部分代码的可读性。
最坏的注释就是过时或者错误的注释，这对于代码的维护者（也许就是几个月后的自己）是巨大的伤害，惋惜除了code review，并没有简朴易行的方法来保证代码与注释的同步。

函数

函数的单一职责
一个函数应该只做一件事，这件事应该能通过函数名就能清楚的展示。判断方法很简朴：看看函数是否还能再拆出一个函数。
函数要么做什么do_sth, 要么查询什么query_sth。最恶心的就是函数名表示只会query_sth, 但事实上却会do_sth, 这使得函数产生了副作用。比如书中的例子
public class UserValidator {
private Cryptographer cryptographer;
public boolean checkPassword(String userName, String password) {
User user = UserGateway.findByName(userName);
if (user != User.) {
String codedPhrase = user.getPhraseEncodedByPassword;
String phrase = cryptographer.decrypt(codedPhrase, password);
if ("Valid Password".equals(phrase)) {
Session.initialize;
return true;
}
}
return false;
}
}函数的抽象层级
每个函数一个抽象层次，函数中的语句都要在同一个抽象层级，差别的抽象层级不能放在一起。比如我们想把大象放进冰箱，应该是这个样子的：
def pushElephantIntoRefrige:
openRefrige
pushElephant
closeRefrige函数里面的三句代码在同一个层级（高度）描述了要完成把大象放进冰箱这件事顺序相关的三个步骤。显然，pushElephant这个步骤又可能包含很多子步骤，但是在pushElephantIntoRefrige这个层级，是无需知道太多细节的。
当我们想通过阅读代码的方式来了解一个新的项目时，一样寻常都是采取广度优先的计谋，自上而下的阅读代码，先了解整体结构，然后再深入感爱好的细节。如果没有对实现细节进行精良的抽象（并凝练出一个名副其实的函数），那么阅读者就容易迷失在细节的汪洋里。
某种程度看来，这个跟金字塔原理也很像

                               
登录/注册后可看大图
每一个层级都是为了论证其上一层级的观点，同时也必要下一层级的支持；同一层级之间的多个论点又必要以某种逻辑关系排序。pushElephantIntoRefrige就是中心论点，必要多个子步骤的支持，同时这些子步骤之间也有逻辑先后顺序。
函数参数
函数的参数越多，组合出的输入情况就愈多，必要的测试用例也就越多，也就越容易出问题。
输出参数相比返回值难以明白，这点深有同感，输出参数实在是很不直观。从函数调用者的角度，一眼就能看出返回值，而很难识别输出参数。输出参数通常逼迫调用者去检查函数签名，这个实在不友好。
向函数传入Boolean（书中称之为 Flag Argument）通常不是好主意。尤其是传入True or False后的行为并不是一件事情的两面，而是两件差别的事情时。这很明显违背了函数的单一职责约束，解决办法很简朴，那就是用两个函数。
Dont repear yourself
在函数这个层级，是最容易、最直观实现复用的，很多IDE也难帮助我们讲一段代码重构出一个函数。
不过在实践中，也会出现这样一种情况：一段代码在多个方法中都有使用，但是又不完全一样，如果抽象成一个通用函数，那么就必要加参数、加if else区别。这样就有点尴尬，貌似可以重构，但又不是很完善。
造成上述问题的某种情况是由于，这段代码也违背了单一职责原则，做了不只一件事情，这才导致欠好复用，解决办法是进行方法的细分，才能更好复用。也可以考虑template method来处理差异的部分。

测试

非常惭愧的是，在我经历的项目中，测试（尤其是单位测试）一直都没有得到足够的器重，也没有试行过TDD。正由于缺失，才更感精良测试的贵重。
我们常说，好的代码必要有可读性、可维护性、可扩展性，好的代码、架构必要不停的重构、迭代，但主动化测试是保证这一切的基础，没有高覆盖率的、主动化的单位测试、回归测试，谁都不敢去修改代码，只能任其腐烂。
即使针对焦点模块写了单位测试，一样寻常也很随意，以为这只是测试代码，配不上生产代码的职位，以为只要能跑通就行了。这就导致测试代码的可读性、可维护性非常差，然后导致测试代码很难跟随生产代码一起更新、演化，最后导致测试代码失效。所以说，脏测试 - 等同于 - 没测试。
因此，测试代码的三要素：可读性，可读性，可读性。
对于测试的原则、准则如下：
测试的FIRST准则：

                               
登录/注册后可看大图




欢迎光临 创意电子 (https://wxcydz.cc/) Powered by Discuz! X3.4