i6448038 / i6448038.github.io

我的个人博客,欢迎关注

Home Page:https://i6448038.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

代码整洁之道

i6448038 opened this issue · comments

第一章

第一章即可以作为全书的开始,又是全书的总结:主要讲了“哪怕是编程语言越来越方便的未来,作为程序猿还是要注意代码质量的;代码的质量和团队的生产力、甚至整个公司的前途都有直接或者间接的联系;然后作者而是引用了很多大神的经典名言,来描述整洁代码的样子。”然后我有一点感想:首先我们要明白一点,写代码是给谁看的?是给人看的,代码从打孔纸带纸带开始到现在的各种高阶语言,其实都是在做一件事情:就是控制流程。(具体的可能底层是通过地址总线 获取了内存的某个xxx,然后通过计算单元对xxx做加工,然后又放到某个地址上去xxx;无限的循环这个步骤。)我们的代码最终是和机器的控制单元密切配合实现了计算机世界的一切。

我们所使用的计算机语言由最初的指令 中间经过无数的中间层,最终变成了符合人类的语言,有些字段甚至直接有了人类的文字。代码最终是给人看的,书中说写代码想画画,我觉得写代码更像是写文章,毕竟代码中直接有人类的语言。
我总结了一点我认为代码整洁的样子:
1、简单直接
2、严格按照某种规范(分层策略、代码规范、语言规范)
3、代码之间无依赖,函数保证无状态
4、代码量少

第二章

1、选用好的名称,要名副其实
2、避免信息的误导,例如:“accountList”这个单词,“List”在程序世界中是有特殊含义的:“列表”,如果真是这样表达,可能会有问题。
3、数字系列命名毫无意义:1、2、3、4;废话是另一种没有意义的区分:例如product 和 productInfo;
4、名称长短应与其作用域大小相对应
5、类名对象名为名词,方法为动词
6、加前缀增加有意义的语境。例如:firstName 改为 addrfirstName
7、保持尽量的简短

第三章

1、函数应该尽可能的短小,做好一件事,只做这一件事
2、向下规则:每一个函数后面都跟着位于下一抽象层级的函数,可以循抽象层级向下阅读;这很难,程序猿往往只能写出停留在一个抽象层级的函数
3、无法确保switch都埋藏在较低的抽象层次;我们可以利用多态来实现
4、 如果每个例程都让你干到深合己意;不要害怕长名称、不要害怕花时间起名字
5、 函数参数:应该尽量避免3个以上的参数,如果有3个以上的参数,就应该做一下封装了;标识参数不应该传入(例如:bool类型的flag函数)
6、每个函数、代码块 都应该有一个入口,一个出口,遵循这些原则,意味着在每个函数中只应该有一个return语句,循环中不能有break或者continue语句

第四章

1、代码也就是一种不必要的恶,如果编程语言有足够的表达力,就不需要注释
2、好注释:1、法律信息 2、返回信息注释 3、对意图的解释 4、阐释 5、警示 6、todo 7、放大意思
不过要记住,唯一真正好的做法是你想办法不去写注释
3、坏注释:坏注释都是糟糕的代码的支撑或者借口,或者是对错误决策的修正,基本上等于程序猿自说自话;不要注释掉代码,要直接删掉

第五章

代码格式关乎沟通,而沟通是专业开发者的头等大事
1、相同思路的代码不用空格,不同思路的代码用空格隔开
2、为读代码方便,避免一个函数跳到另外一个函数,最后找不到原来函数的尴尬局面,最好是将关系密切概念的代码相互靠近。
变量声明:放到函数顶部
实体变量:放到类的顶部
相关函数:相互调用的函数放到一起,而且调用者应该尽可能放在被调用者上面
3、代码行宽度:80~ 120个字符为最佳,不然看起来费劲
4、团队规则:每个程序员都有自己喜欢的格式规则,但如果在团队中工作,就是团队说了算