什么是代码整理?
这是kent Beck大师有关一篇编码工艺的文章:
在“改变生活的魔法”一文中,我描述了一种零碎的、日常代码卫生学,代码将变得混乱。好像没有没有羞耻感吗,看到代码杂乱表明你已经学到了一些东西,整理就是做一些关于凌乱代码的事情。
TLCMOTUC描述了整理过程:让事情变得更好,保持安全,庆祝进步。以下是一些需要整理的内容:
名称
随着时间的推移,名称和意义可能会分开,团队使用的词汇不断发展,昨天的话可能不是今天的话。
整洁的名字是一次一个,让下一位读者理解更容易一些。
条件语句
条件逻辑是很好整理的,你希望代码阅读者查看条件时,能立即了解发生的情况。条件的某些用法会掩盖了程序员的意图。
错误使用条件的一种方式是隐藏简单案例:
|
整理成:
|
条件的意思是:“这里有两种可能的计算路径。”然而,有时程序员想说,“这是一个先决条件。如果不满足,则此计算无效/无必要。“例如,如果缓存了值,则无需计算值。
|
这段代码实际上并不是两个条件同样平衡的,它是有一个先决条件,如果不满足才计算,使用Guard子句整理好:
|
返回缓存;
下一位读者会感谢你。
最后,有时程序员的意思是“按两种方式中的一种计算值”,而不是“遵循这两种执行方式中的一种”,整理这个:
|
要使用三元运算符:
|
冗余
随着代码的发展,本地优化的编程决策可能会留下混乱,这里就有余地实现更短、更清晰的替换。通过一次修复这些斑点来整理,将“if(flag == true)”替换为“if(flag)”(假设您的编程语言支持此项);将“collection.size == 0”替换为“collection.isEmpty”。
这种整理的想法是找到一种表达计算的主导统一方式,这样能更短,更清晰地表达,而且在各方面都更好。
一个更极端的例子是当使用异常处理时,函数的返回值还能正常使用,不要使用比必要的更大的棍子。
萃取Extraction
表达式可以从简单开始然后再增长,在每个步骤中,添加比分解更容易,这里有需要整理的地方。
提取部件,并为临时变量提供暗示名称,这是一种整理表达式方式,如:
|
整理成:
|
在整理它时完全可以提取单个解释变量,稍后才有时间整理表达的其余部分。
提取例程也可以整理,所有人性化的IDE现在都支持自动提取功能。整理时,对函数可自由提取为一种helper性质函数,稍后才有时间调用您的新helper函数。
一个更雄心勃勃的(也许我应该说“勇敢”)整理是提取一个方法对象。方法对象通常可以实现戏剧性的后续清理。在整理时只需提取成新对象并调用即可,许多工作其实只需要一次代码提交就完成。
重新排序
最后的整理是按照读者想要的顺序对文件中的元素进行排序。取决于你的代码阅读者,可能会先将所有帮助程序放在最后;然后将主逻辑流程放在最后;或者可能先拥有主流程,然后再执行帮助程序等。
|
要么 主在前:
|
在重新排序时,可能会看到其他整理的可能性。那就不得不等待下一个差异。完成重新排序并进行整理,然后再整理一些。
总结
写这篇文章时我很惊讶。我曾经一直说,“保持很小的整理差异,因为以后会有时间再进行更多的整理。”那种以后会有足够时间的态度与我通常的情况完全相反,他们会说“我们现在必须清理,因为我们永远不会有另一次机会。”
如果你有足够的时间,你会怎么样?尝试一下,也许额外的能量、创造力和整洁性将使你能够完成更多整理,而不是更少,每次只整理一点,等有时间再进行更多整理,也许会有更多惊喜发现,那多酷啊!
但是,整理不能变为程序添加新逻辑,这是一个富有成效的小工具微调器,当你知道你想写什么,然后写它,后面再整理。