代码整洁之道
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
代码整洁之道
2015年12月 梅花与剑
目录
04 代码健壮性 01 代码的坏味 道 03 代码可读性
02 编码原则 06 关于日志 05 异常处理
08 代码习惯 09 设计模式
07 关于性能
10 关于重构
这是哪个傻X 写的代码 ！！！
代码如何变烂的？
• 世上本没有BUG • 随着功能的增加，便有了BUG • 老的BUG改了，可能引入新的BUG • 事实1： 我们的软件，在发布前，其实就 已经百病缠身了。
由于运行环境的不同，有些返回1，有些返回0
代码可读性—— 注释
• • • • 文件头标注开发者、功能、开发时间、最后修改时间、修改详情； 方法头标注功能、输出参数、输入参数； 方法体内重要代码及疑难代码行内注释； if else类代码优先考虑标注，标注在右大括号之后；
代码可读性——判断中尽量少用“非”
看一段代码 int a=2; int b=5; if(!(a!=1&&b==5)){ System.out.println(“条件1”); }else{ System.out.println(“条件2”); } 请问输出是什么？ 如果觉得这还不够，那看看 “我不得不否认,你不是个笨蛋”，这句话是什么意思：） 杜绝双重否定的出现，代码是用来给人读的
八大原则
代码可读性——目录结构
web工程：
测试目录编译后的class文件存放目录 数据库建库脚本目录 Java目录 Java测试目录 Web目录
src：
业务处理基类 读取配置文件db_config.xml
数据库操作封装
webapp：
日志操作封装
图片目录 不同类的图片放在不同目录下
Servlet基类
代码可读性—— i++ 和 ++i
看一段代码： public class TestStatic { static { int x =5; } static int x,y; public static void main(String arg[]) { x++; method(); } public static void method() { System.out.println(x++ + ++y); } } X和y分别是多少 不要写这类代码，这种代码是用来考机器的，对于我们要写的代码，请写大家看得懂的代码 真实代码： Public Class Counter{ private int counter=0; public int getCounter(){ return ++counter; } }
代码的坏味道
熟悉代码的坏味道，并知道这里需要重构，代码的坏味道（部分）：
重复代码—拷贝粘贴再修改的痕迹(提取公共逻辑)
过长的方法—函数体超过50行，实现了多个逻辑（Extract Method） 过大的类—类做了太多的事情（Extract Class）
过长的参数列—方法难于使用和理解（参数Object化）
各种引入文件 如样式文件、脚本文件、jsp头尾文件
常用操作类封装
jsp文件目录，按业务功能模块拓展，与java业务模块划分对应 common是公共内容，如错误提示、分页等
class文件、第三方jar包、Leabharlann Baidu置文件
按业务功能模块拓展 控制类继承base下的Servlet基类 业务类继承base下的业务处理基类 配置文件（数据库配置和日志配置）
代码可读性——包、类、方法、属性、常量的命名规范
my name 可能的写法：myname、my_name、MyName或者myName。 两种常用命名方法： 驼峰式命名：printEmployeePaychecks()；函数名中的每一个逻辑断点都有一个大写字母来标记 下划线法命名：print_employee_paychecks()；函数名中的每一个逻辑断点都有一个下划线来标记 骆驼式命名法就是当变量名或函式名是由一个或多个单字连结在一起，而构成的唯一识别字时，第一个单词以 小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母。 小驼峰法：除第一个单词之外，其他单词首字母大写。譬如 int myStudentCount; 大驼峰法：相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。譬如public class DataBaseUser; Package 的命名 Package 的名字应该都是由一个小写单词组成。 Class 的命名 Class 的名字必须由大写字母开头而其他字母都小写的单词组成，大驼峰法 Class 变量的命名 变量的名字必须用一个小写字母开头。后面的单词用大写字母开头，小驼峰法 Static Final 变量的命名 Static Final 变量的名字应该都大写，并且指出完整含义，下划线法 方法的命名 方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。小驼峰法
原则
低质量代码存在的问题： 难于变化—一处变化导致其它很多部分，特别是无关部分的修改 难于重用—系统关联性过多，导致很难分离可重用部分 不必要的复杂—设计过于复杂，不利于当前编码 不必要的重复—同样的逻辑多处出现，未进行抽象的统一 难于理解—命名杂乱，结构混乱，难于阅读和理解 难于测试和验证—过多依赖其它系统，缺乏完善测试体系，难于验证 高质量的代码编写原则： 每个变量只用于单一用途 每一行代码只表达一件事 一个循环只做一件事 单一抽象层次原则 函数应该遵守单一职责 函数圈复杂度应该小于10 函数第一原则是必须要短小 编写函数时必须一心一意、专注、怀有谦虚的心态
变化导致太多修改—变化引起多个类的修改（Move方法到该放的地方） 依恋情节—一个类的实现大量引用另一个类的数据（Move方法）
Switch语句—对不同类别使用switch（使用多态）
临时变量—临时变量不易于理解和抽取（Replace Temp with Query） 过度设计—过多的抽象和代理（先简单设计，变化来临时再重构） 不用的方法—子类不需要使用父类的方法（改变类层次） 违背了一些原则—后面会详细讲原则及违背带来的影响
2015年12月 梅花与剑
目录
04 代码健壮性 01 代码的坏味 道 03 代码可读性
02 编码原则 06 关于日志 05 异常处理
08 代码习惯 09 设计模式
07 关于性能
10 关于重构
这是哪个傻X 写的代码 ！！！
代码如何变烂的？
• 世上本没有BUG • 随着功能的增加，便有了BUG • 老的BUG改了，可能引入新的BUG • 事实1： 我们的软件，在发布前，其实就 已经百病缠身了。
由于运行环境的不同，有些返回1，有些返回0
代码可读性—— 注释
• • • • 文件头标注开发者、功能、开发时间、最后修改时间、修改详情； 方法头标注功能、输出参数、输入参数； 方法体内重要代码及疑难代码行内注释； if else类代码优先考虑标注，标注在右大括号之后；
代码可读性——判断中尽量少用“非”
看一段代码 int a=2; int b=5; if(!(a!=1&&b==5)){ System.out.println(“条件1”); }else{ System.out.println(“条件2”); } 请问输出是什么？ 如果觉得这还不够，那看看 “我不得不否认,你不是个笨蛋”，这句话是什么意思：） 杜绝双重否定的出现，代码是用来给人读的
八大原则
代码可读性——目录结构
web工程：
测试目录编译后的class文件存放目录 数据库建库脚本目录 Java目录 Java测试目录 Web目录
src：
业务处理基类 读取配置文件db_config.xml
数据库操作封装
webapp：
日志操作封装
图片目录 不同类的图片放在不同目录下
Servlet基类
代码可读性—— i++ 和 ++i
看一段代码： public class TestStatic { static { int x =5; } static int x,y; public static void main(String arg[]) { x++; method(); } public static void method() { System.out.println(x++ + ++y); } } X和y分别是多少 不要写这类代码，这种代码是用来考机器的，对于我们要写的代码，请写大家看得懂的代码 真实代码： Public Class Counter{ private int counter=0; public int getCounter(){ return ++counter; } }
代码的坏味道
熟悉代码的坏味道，并知道这里需要重构，代码的坏味道（部分）：
重复代码—拷贝粘贴再修改的痕迹(提取公共逻辑)
过长的方法—函数体超过50行，实现了多个逻辑（Extract Method） 过大的类—类做了太多的事情（Extract Class）
过长的参数列—方法难于使用和理解（参数Object化）
各种引入文件 如样式文件、脚本文件、jsp头尾文件
常用操作类封装
jsp文件目录，按业务功能模块拓展，与java业务模块划分对应 common是公共内容，如错误提示、分页等
class文件、第三方jar包、Leabharlann Baidu置文件
按业务功能模块拓展 控制类继承base下的Servlet基类 业务类继承base下的业务处理基类 配置文件（数据库配置和日志配置）
代码可读性——包、类、方法、属性、常量的命名规范
my name 可能的写法：myname、my_name、MyName或者myName。 两种常用命名方法： 驼峰式命名：printEmployeePaychecks()；函数名中的每一个逻辑断点都有一个大写字母来标记 下划线法命名：print_employee_paychecks()；函数名中的每一个逻辑断点都有一个下划线来标记 骆驼式命名法就是当变量名或函式名是由一个或多个单字连结在一起，而构成的唯一识别字时，第一个单词以 小写字母开始；第二个单词的首字母大写或每一个单词的首字母都采用大写字母。 小驼峰法：除第一个单词之外，其他单词首字母大写。譬如 int myStudentCount; 大驼峰法：相比小驼峰法，大驼峰法把第一个单词的首字母也大写了。譬如public class DataBaseUser; Package 的命名 Package 的名字应该都是由一个小写单词组成。 Class 的命名 Class 的名字必须由大写字母开头而其他字母都小写的单词组成，大驼峰法 Class 变量的命名 变量的名字必须用一个小写字母开头。后面的单词用大写字母开头，小驼峰法 Static Final 变量的命名 Static Final 变量的名字应该都大写，并且指出完整含义，下划线法 方法的命名 方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。小驼峰法
原则
低质量代码存在的问题： 难于变化—一处变化导致其它很多部分，特别是无关部分的修改 难于重用—系统关联性过多，导致很难分离可重用部分 不必要的复杂—设计过于复杂，不利于当前编码 不必要的重复—同样的逻辑多处出现，未进行抽象的统一 难于理解—命名杂乱，结构混乱，难于阅读和理解 难于测试和验证—过多依赖其它系统，缺乏完善测试体系，难于验证 高质量的代码编写原则： 每个变量只用于单一用途 每一行代码只表达一件事 一个循环只做一件事 单一抽象层次原则 函数应该遵守单一职责 函数圈复杂度应该小于10 函数第一原则是必须要短小 编写函数时必须一心一意、专注、怀有谦虚的心态
变化导致太多修改—变化引起多个类的修改（Move方法到该放的地方） 依恋情节—一个类的实现大量引用另一个类的数据（Move方法）
Switch语句—对不同类别使用switch（使用多态）
临时变量—临时变量不易于理解和抽取（Replace Temp with Query） 过度设计—过多的抽象和代理（先简单设计，变化来临时再重构） 不用的方法—子类不需要使用父类的方法（改变类层次） 违背了一些原则—后面会详细讲原则及违背带来的影响