注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

樱之花

叶散的时候,你明白欢聚;花谢的时候,你明白青春.

 
 
 

日志

 
 
关于我

分类中“我的实验室”是我在日常工作中的一些知识总结,有些写的比较匆忙,可能大家在阅读时会产生困扰,后期有时间我会重新整理编辑,谢谢大家的到访,您们的支持是我前进的动力!

网易考拉推荐

代码整洁之道读书笔记  

2012-03-04 16:39:24|  分类: 代码重构 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

读书笔记
  第一章 整洁代码
  1,整洁代码力求集中,每个函数、每个类和每个模块都全神贯注于一件事。
  2,整洁代码简单直接,从不隐藏设计者的意图。
  3,整洁代码应当有单元测试和验收测试。它使用有意义的命名,代码通过其字面表达含义。
  4,消除重复代码,提高代码表达力。
  5,时时保持代码整洁。
  
  第二章 有意义的命名
  1,使用体现本意的命名能让人更容易理解和修改代码。
  2,编程本来就是一种社会活动。
  3,尽力写出易于理解的代码
  
  第三章 函数
  1,一个函数应该只做一件事(高内聚),无副作用。
  2,自顶向下阅读代码,如同是在阅读报刊文章。
  3,长而具有描述性的函数名称,好过描述性的长注释。
  4,少用输出参数。
  5,拒绝boolean型标识参数。
  例: CopyUtil.copyToDB(isWorkDB) --> CopyUtil.copyToWorkDB(), CopyUtil.copyToLiveDB()
  6,使用异常代替返回错误码,错误处理代码就能从主路径代码中分离出来得到简化。
  7,写代码很像是写文章。先想怎么写就怎么写,然后再打磨:分解函数、修改名称、消除重复。
  8,编程其实是一门语言设计艺术,大师级程序员把程序系统当做故事来讲。使用准确、清晰、富有表达力的代码来帮助你讲故事。
  
  第四章 注释
  1,别给糟糕的代码加注释----重写吧。
  2,把力气花在写清楚明白的代码上,直接保证无需编写注释。
  3,好的注释:
  法律信息
  提供信息
  解释意图
  警示
  TODO注释
  
  第五章 格式
  1,代码格式很重要。代码格式关乎沟通,而沟通是专业开发者的头等大事。
  2,向报纸格式学习代码编写。
  
  第六章 对象和数据结构
  1,对象把数据隐藏于抽象之后,只提供操作数据的函数。
  数据结构暴露其数据,没有提供有意义的函数。
  2,The Law of Demeter:模块不应去了解它所操作的对象内部细节。
  
  第七章 错误处理
  1, 使用异常而非返回错误码.
  2, try-catch-finally, log出错信息.
  3, 不要返回null,不要传递null。
  NULL Object模式, 例:Collections.emptyList();
  
  第十章 类
  1,自顶向下原则:让程序读起来就像是一篇报纸文章。
  2,method可以是protected,以便于单元测试。
  3,SRP:类或模块应有且仅有一个加以修改的原因。类名应准确描述其职责。高内聚。
  4,开放闭合原则OCP、依赖倒置原则DIP
  5,变量名、方法名、类名都是给代码添加注释的一种手段。
  
  第十二章 迭代前进
  1, 紧耦合的代码难以编写单元测试。
  2,单元测试消除了对清理代码会破坏代码的恐惧。
  3,写出自己能理解的代码很容易,软件项目的主要成本在于长期维护。
  4,代码应当清晰表达其作者的意图;测试代码可以通过实例起到文档作用。
  
  第十四章 逐步改进
  1,编程是一种技艺。要编写整洁代码,必须先容忍脏代码,然后清理!
  2,写出好文章就是一个逐步改进的过程。

整理其中一些建议
   1. 与其写啰嗦的注释,不如重构代码(比如重命名方法名,变量,或者把代码分离到不同方法)来替代没必要的注释
   2. 方法参数越少越好,除非有人逼你这么做,不要超过2个参数。当你发现你非用2以上参数不可,考虑把一部分参数抽象出来做一个类。
   3. 用给自己孩子起名一样的谨慎心态给变量,方法起名。
   4. 自上向下的代码放置规则:先放置首层抽象级别的第一段代码,而后紧跟其相关的第二抽象级别代码,如果有第三层继续。 依此类推,便于他人以逻辑顺序从上到下阅读
   5. 同一方法中的语句都要在同一抽象级别
   6. High Cohesion 能给代码带来良好阅读性以及维护性
   7. try, catch 最好不要嵌套,如果有就把嵌套的那部分try,catch抽离出来到一个抛出异常的方法中。
   8. The Law of Demeter, 代码模块不应该了解其操作的对象的内部结构, 也就是说她不应该调用任何方法返回的对象的方法(也就是“连续调用”), 应该把那段“连续调用”抽象到一个方法中,从而隐藏其结构
   9. Open for extension, close for modification.
   10. Dependency Inversion Principle, DIP, 类应该“依赖”于抽象,而不是具体实现。 这样子可以减少耦合
   11. 所谓边界,使用第三方代码的时候,需要把原来API做适当包装,只暴露一些我们期待用户使用的接口,隐藏一些不需要的接口。利用适配器模式。
   12. 高内聚意味着类中的变量都最大程度地被每个方法使用,应该保持类的高内聚性。单一职权原则(SRP) 的结果是,分离出很多短小精悍的小类。

  评论这张
 
阅读(690)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017