CleanCode
2019-09-23 17:57:23 1 举报AI智能生成
代码整洁
作者其他创作
大纲/内容
命名
名副其实
变量、函数、类的名称应该已经答复了所有的大问题
如果名称需要注释来补充，那就不叫做名副其实
避免误导
如accountList来指称一组账号，除非他真的是List类型。List一次对程序员是有特殊含义的。
做有意义的区分
如accountList来指称一组账号，除非他真的是List类型。List一次对程序员是有特殊含义的。
如同 a,an和the的区别
使用读得出来的名称
人类擅于记忆和使用单词，大脑相当一部分就是用来容纳和处理单词的
如：genymdhms,简直不能望文生义
使用可搜索的名称
单字母名称和数字变量有个问题，就在很难在一大篇文字中找出来
长名称胜于短名称，搜得到的名称胜于自构造编码的名称
类名和对象应该是名词和名词的组合
如Customer，Account
方法名
应当是动词或动词短语
如postPayment，deletePage或saveUserName等
名称简明扼要，别装可爱
如果名称太耍宝，那就只有和同作者一样的幽默感的人才能记得住，更get到点的人才能记住
每个概念对应一个词
在同一堆代码中有controller，又有manager还有driver。就会令人困惑
为什么不全用controller或者manager？
别用双关语
避免将同一单词用于不同的目的，同一术语用于不同的概念
添加有意义的语境
time-->workouttime
state--->addState
函数
短小
20行封顶最佳可读性
Kent Beck
软件开发方法学的泰斗，敏捷开发开创者之一，junit作者
只做要一件事
单一职责
每一个函数有一个抽象层级
自顶向下读代码：向下原则
switch语句
使用多态重构它
使用描述性名称
数越短小，功能越集中，就越便于取个好名字
长而具有描述性的名称，比短小而费解的名称要好
函数参数
最理想的而函数参数是零，其次是一，再次是二，应尽量避免三，
超过三个的参数应考虑封装成类了
标识参数
违反了只做一件事原则，ture/false
一元函数
动词、名词对是一种良好形式 eg:write(name)
二元函数
如assertEquals(excepted,actual)也存在问题，你有多少次搞错他们两的位置呢？
Point p = new Point(1.0)
三元函数
考虑重构，分解成一元或二元函数
无副作用
不要违反“只做一件事情”的原则
分割指令与询问
函数应该修改某对象的状态或是返回该对象的有关信息，两样都敢常会导致混乱
add与append
使用异常替代返回错误码
抽离try/catch代码块
最好把try/catch代码块的主体抽离出来，形成函数
错误处理就是一件事
函数应该只做一件事。错误处理就是一件事
函数应该只做一件事。错误处理就是一件事
如果关键字try在某个函数中存在，它就该是这个函数的第一个单词，而且在catch/finally代码块后面不该有其他内容。
Error.java依赖磁体
包含了所有错误码的枚举类，当此类修改是，所有这些其他的类都要重新编译和部署
使用异常代替，新异常就可以从异常类派生出来，无需重新编译或者部署
别重复自己
许多原则与实践规则都是为控制与消除重复而创建
避免重复的代码，适时封装成类
注释
能用diamante来阐述，就不需要注释
什么是好的注释？
法律信息（版权、著作权声明）
对提供信息的解释
如，String.xml文件中的大多数注释
对意图的解释
某个决定后面的意图
警示
提醒开发者可能存在的问题
注释代码
千万别这么干
我们拥有这么成熟的源代码控制系统，如果真的不需要就直接删掉把，丢不了！！！！警戒自己
格式
格式的目的
个人开发应该保持良好的格式，团队开发更应如此
什么是开发过程中最重要的事情呢？
沟通，而良好的代码格式有利于沟通
值得学习的格式
垂直格式
向报纸学习
名称应当一目了然
源文件的顶部应当给出高层次概念和算法
细节逐次展开
垂直方向上的间隔
每个函数应该用空白行隔开
垂直顺序
被调用的函数应当在执行调用函数的下面
横向格式
水平方向上的区隔与靠近
区隔
运算符之间的空格，如“=”
靠近
函数名与参数括号
团队格式
善于代码格式插件管理源文件
对象和数据结构
看一个例子
对象
把数据隐藏于抽象之后(自己内部)，暴露操作数据的函数
面向对象
添加新数据结构变得容易
不改变既有函数，每种数据类型互不干扰
添加新的函数变得困难
修改每个数据类型
数据结构
暴露数据，而没有提供有意义的函数
面向过程
添加函数变得容易，不用修改既有数据结构
添加新数据结构变得困难
新增数据结构需要修改已存在的函数
二分原理
两种方法使互补的，相反的
合适的地方用合适的方法
德墨忒定律
模块不应了解它所操作对象的内部情形
火车失事
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
错误处理
使用异常而非返回码
只需新增派生异常类，而无需修改错误枚举类
别返回null
返回一个特例对象
别传递null
做好错误处理，可以帮助我们写出整洁而强固的代码
类
类的封装
自顶向下原则：善于protected成员
类应该短小
单一职责
类或模块有且只有一个引起变化的原因
内聚
保持高内聚就能得到许多短小的类
为修改而组织
针对违反单一职责的部分执行组织
使用接口、抽象类隔离细节变化带来的影响
0 条评论
下一页
为你推荐
查看更多
抱歉，暂无相关内容 
