首页  流程图  详情

代码整洁之道内容详细图解第一部分

2022-10-06 14:34:05   11  举报





为你推荐

查看更多



读书笔记，增加第 5 章内容

后端

作者其他创作

大纲/内容

查询使用一种风格◯ User queryUser(String userId);◯ User batchQueryUser(List<String> userIds);

1.2 糟糕的代码

什么也不会比乱七八糟的注释更有本事搞乱一个模块，什么也不会比陈旧、提供错误信息的注释更有破坏性注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败

- 公共API 中的Javadoc

函数的第一规则时要短小，第二规则是还要更短小每个函数都一目了然，每个函数都只说一件事注意代码块和缩进，函数中不应有过多的缩进层级

只做一件事

坏注释

读与写时间的比例超过 10：1

整洁的代码只做好一件事：整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染

参考：

- 阐释 assertTrue(b.compareTo(a) == 1); // b > a

本书是编程大师“Bob大叔”40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。

单独链接：https://www.processon.com/view/link/634822c81e0853378e4621d0

代表作：

1.3 混乱的代价

好注释

软件中随处可见命名，我们给变量、函数、参数、类和包命名，给源代码及源代码所在目录命名；我们命名、命名，不断命名既然有这么多命名要做，不妨做好它选个好名字要花时间，但省下来的时间比花掉的多

勒布朗法则：稍后等于永不

- 循规式注释- 日志式注释- 废话注释 // the day of the month private int dayOfMonth;

第4章注释

查询使用不同风格◯ User getUser(String userId);◯ User batchQueryUser(List<String> userIds);

第5章格式

第6章对象与数据结构

- 警示 // Don't run unless you have some time to kill

重复可能是软件中一切邪恶的根源软件开发领域的所有创新都是在不断尝试从源代码中消灭重复

示例代码

✓

随着混乱的增加，团队生产力也持续下降，以致趋向于零

初期为了推出产品，代码写的乱七八糟，特性越多代码也越乱，最后将没办法管理这些代码

Javadoc 中的 @author 字段告诉我们自己是什么人。我们是作者。作者也是读者

病人请求你在给他做手术前别洗手，因为那会花费太多时间，你会照办嘛？

- 多余的注释 // Utility method that returns shen this.closed is true.

写整洁代码像绘画，能分辨出整洁代码和肮脏代码，也不意味着会写整洁代码

✘

金玉良言

添加有意义的语境

重构：先写出函数，再打磨代码，分解函数、修改名称、消除重复

- 误导性的注释

垂直格式

第2章有意义的命名

第二部分：需要反复练习的案例研究

我们都曾嫖一眼自己亲手造成的混乱，决定起之不顾，走向新一天。我们都曾经说过有朝一日再回头清理。

破窗效应：环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上

每一个概念对应一个词

我们永远抛弃不掉代码，因为代码呈现了需求的细节在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事而这种规约正是代码

短小

Robert C. Martin（罗伯特·C·马丁），作为世界级软件开发大师、设计模式和敏捷开发先驱、C++ Report杂志前主编，也是敏捷联盟（Agile Alliance）的第一任主席，后辈程序员亲切地称之为“Bob大叔”。如今，年逾六十的 Bob 大叔过着典型的“斜杠”生活，他不仅是优秀的程序员、畅销书作家、演讲家，以及视频制作者，还是一名柔术爱好者。现在，Bob 大叔也常常在 Twitter 的账号（@Uncle Bob Martin）以及个人网站（cleancoder.com）上发表自己的观点、文章。

本章所讲述的是有关编写良好函数的机制。如果你遵循这些规则，函数就会短小、有个好名字，而且被很好地归置。不过永远别忘记，真正的目标在于讲述系统的故事，而你编写的函数必须干净利索落地拼装在一起，形成一种精确而清晰的语言，帮助你讲故事。

◯ 不同的内容之间应用空白行区隔开来（如包声明、导入声明、函数之间） ◯ 关系密切的概念应该相互靠近 ◯ 变量生命应尽可能靠近其使用位置 ◯ 实体变量应该在类的顶部声明 ◯ 若某个函数调用了另一个，就应该把他们放到一起

我们不愿意保留数据细节，而更愿意以抽象形态表示数据。这并不意味着只是用接口或赋值器、取值器就万事大吉，要以最好的方式呈现某个对象包含的数据，需要进行严肃的思考。随机添加取值器和赋值器是最坏的选择对象把数据隐藏域抽象之后，暴露操作数据的函数；而数据结构暴露其数据，没有提供有意义的函数

函数应该做一件事，做好这件事，只做这一件事判断是否只做了一件事：1、是否存在多个区段；2、是否能再拆出一个函数3、函数中的语句都要在同一个抽象层级上

内容简介

样式参考：《枪炮、病菌与钢铁》图解：https://www.processon.com/view/6262c62de0b34d517985e3a6?fromnew=1《学习突围》读书笔记：https://www.processon.com/view/6305efa163768906ff61a84c?fromnew=1内容参考：代码整洁之道读书笔记：https://www.processon.com/view/5b6ba82fe4b0555b39daa297?fromnew=1代码整洁之道：https://www.processon.com/view/60dede90e401fd7e342b3fc3?fromnew=1代码展示工具：carbon：https://carbon.now.sh/

《代码整洁之道》

原作名: Clean Code: A Handbook of Agile Software Craftsmanship作者: [美] Robert C. Martin 译者: 韩磊出版社: 人民邮电出版社出版年: 2010-1（英文版：2008-8）页数: 387 定价: 99.00元

◯ 增加空白行区隔不同逻辑◯ 实体变量生命在顶部◯ 逻辑相关的函数放在一起

1.1 要有代码

使用读得出来的名称

假使你是位医生，病人请求你在给他做手术前别洗手，因为那会花费太多时间，你会照办嘛

- 喃喃自语 // No properties files means all defaults are loadded

完整的命名，或是通用的缩写◯ int generationTimeStamp;◯ String msg;

调整后代码

第一部分：介绍整洁代码的原则、模式和实践

最理想的参数数量是0，只有一个输入参数算是第二好的做法标识参数的函数应当进行重构，应当将函数进行拆分

本书中充满了细节，代码会很多，你会看到好代码，也会看到糟糕的代码；会看到糟糕的代码如何转换好代码，会看到一个又一个例子但最终结果取决于你自己小提琴家问长者，如何才能去卡耐基音乐厅，长者说道：『你还得练，孩子，还得练！』