2015 April 11

读编写可读代码的艺术

代码应当易于理解

代码的写法应当使他人理解代码所需要的时间最小化————很多时候几个月之后的你就是那个他人,你会完全无法理解当时的自己。

命名的讲究

把信息装到名字里

  • 使用更有表现力的动词——不是万能Get以及Set,还有其他的单词,如Search、Create、etc
  • 避免泛泛而谈的不精确词汇——万能temp造成的信息模糊
  • 利用具体的词汇、给出信息丰富的命名——让命名附加更多信息
  • 附带其他重要属性——匈牙利命名法将变量名类型与信息全部包含进去
  • 命名长度的讲究

小作用域可选用精简短名——大作用域采用更长的名字
丢弃重复性词汇
利用命名格式传递信息——信息一致化,自己的代码中某一类变量格式一定,比如常量用全大写匈牙利,宏利用某某格式等

可误解性命名

凡事多问问自己:名字会被误解成其他含义吗?

  • 注意英语单词的多义性
  • min、max、first、last、begin、end、以及is、has对于布尔值情况的擅用

###代码审美性

  • 一致的代码布局
  • 一致的代码风格
  • 合适的代码分组以及代码块

合理构造新方法去整理代码
合适的时机使用列对齐
确定合适的变量顺序a-z顺序或其他顺序
利用空格或换行构造合适的代码段

个人一致的代码风格比合理的代码风格更重要

合适的代码注释

帮助读代码的人了解得和代码编写时你的知识了解情况一样多

  • 确定什么是不需要注释的,垃圾注释不必要

不要为了注释而注释 一眼就能看懂的代码不要随意加注释
不好的变量名不要通过加注释去改善————改掉那个变量名

  • 合理的注释

记录下你当时的思想
加入代码评论性注释
为代码瑕疵加注释,或者Todo性注释——下一步工作注释 常量加注释
站在读者角度去加注释
全局性注释,如该API在系统中提供XXXX功能性接口
总结性、全局观注释

把你当时的思想记录下来,后期再整理,用更专业的词语去描述

言简意赅的注释

  • 紧凑的注释信息
  • 不确定指代不使用
  • 利用输入输出样例去说明情况
  • 在代码中嵌入注释解释难以理解的函数形参,如Function(/*…….*/)

简明控制流

在约定中条件判断语句中,比较符号左侧是被询问的表达式,可变的————而右侧是固定对比值

尤大表达法————obj=NULL与NULL=obj

避免使用do-while

利用提前返回————精简嵌套情况

拆分长表达式

将超长表达式拆分为易于理解的小代码块————很多程度上,编译器对代码的优化程度超出你的想象,代码的可读性的提升重要性超过那微乎可微的性能提升

布尔表达式的等价变换————德摩根定理

利用逻辑图拆分逻辑组织逻辑判定情况——P86页实例

变量与代码可读性

  • 变量越多,越难跟踪理解其全部动向

减少变量

去除没有价值的临时变量

缩小变量作用域———— 让变量对尽可能少的代码行可见

减少控制流中的变量

为了理解更方便,将代码定义后移,增强相关行代码关联程度,不要一次把所有变量在一起定义

子问题抽取

  • 积极的抽取问题不相关的子逻辑
  • 抽取纯工具代码
  • 通用代码创建
  • 简化接口

把一般代码与项目专有代码分开

代码一次只做一件事

不要让代码功能过于碎片化

描述你的伪码逻辑

橡皮鸭调试法

把你的代码逻辑说出来,清晰的描述你的逻辑

利用自然语言描述解决方案,说出来

精简代码

保持最小代码量,最好理解的代码是没有代码

准确分析需求,在需求范围内完成最精简的工作量

熟悉你的API库,经常熟悉你的吃饭工具

重用库


  • 测试也应当具有可读性
  • 错误消息可读性
  • 简化测试输入
上一篇
下一篇
Loading Disqus comments...
Table of Contents