[TOC]
# url
http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy
# 写优雅的代码
优雅的代码的另一个特征是,它的逻辑大体上看起来,是枝丫分明的树状结构(tree)。这是因为程序所做的几乎一切事情,都是信息的传递和分支。你可以把代码看成是一个电路,电流经过导线,分流或者汇合。如果你是这样思考的,你的代码里就会比较少出现只有一个分支的if语句,它看起来就会像这个样子:
~~~
if (...) {
if (...) {
...
} else {
...
}
} else if (...) {
...
} else {
...
}
~~~
注意到了吗?在我的代码里面,if语句几乎总是有两个分支。它们有可能嵌套,有多层的缩进,而且else分支里面有可能出现少量重复的代码。然而这样的结构,逻辑却非常严密和清晰
# 写模块化的代码
有些人吵着闹着要让程序“模块化”,结果他们的做法是把代码分部到多个文件和目录里面,然后把这些目录或者文件叫做“module”。他们甚至把这些目录分放在不同的VCS repo里面。结果这样的作法并没有带来合作的流畅,而是带来了许多的麻烦。这是因为他们其实并不理解什么叫做“模块”,肤浅的把代码切割开来,分放在不同的位置,其实非但不能达到模块化的目的,而且制造了不必要的麻烦。
真正的模块化,并不是文本意义上的,而是逻辑意义上的。一个模块应该像一个电路芯片,它有定义良好的输入和输出。实际上一种很好的模块化方法早已经存在,它的名字叫做“函数”。每一个函数都有明确的输入(参数)和输出(返回值),同一个文件里可以包含多个函数,所以你其实根本不需要把代码分开在多个文件或者目录里面,同样可以完成代码的模块化。我可以把代码全都写在同一个文件里,却仍然是非常模块化的代码。
想要达到很好的模块化,你需要做到以下几点:
* 避免写太长的函数。如果发现函数太大了,就应该把它拆分成几个更小的。通常我写的函数长度都不超过40行。对比一下,一般笔记本电脑屏幕所能容纳的代码行数是50行。我可以一目了然的看见一个40行的函数,而不需要滚屏。只有40行而不是50行的原因是,我的眼球不转的话,最大的视角只看得到40行代码。
* 如果我看代码不转眼球的话,我就能把整片代码完整的映射到我的视觉神经里,这样就算忽然闭上眼睛,我也能看得见这段代码。我发现闭上眼睛的时候,大脑能够更加有效地处理代码,你能想象这段代码可以变成什么其它的形状。40行并不是一个很大的限制,因为函数里面比较复杂的部分,往往早就被我提取出去,做成了更小的函数,然后从原来的函数里面调用。
* 制造小的工具函数。如果你仔细观察代码,就会发现其实里面有很多的重复。这些常用的代码,不管它有多短,提取出去做成函数,都可能是会有好处的。有些帮助函数也许就只有两行,然而它们却能大大简化主要函数里面的逻辑。
有些人不喜欢使用小的函数,因为他们想避免函数调用的开销,结果他们写出几百行之大的函数。这是一种过时的观念。现代的编译器都能自动的把小的函数内联(inline)到调用它的地方,所以根本不产生函数调用,也就不会产生任何多余的开销。
同样的一些人,也爱使用宏(macro)来代替小函数,这也是一种过时的观念。在早期的C语言编译器里,只有宏是静态“内联”的,所以他们使用宏,其实是为了达到内联的目的。然而能否内联,其实并不是宏与函数的根本区别。宏与函数有着巨大的区别(这个我以后再讲),应该尽量避免使用宏。为了内联而使用宏,其实是滥用了宏,这会引起各种各样的麻烦,比如使程序难以理解,难以调试,容易出错等等。
* 每个函数只做一件简单的事情。有些人喜欢制造一些“通用”的函数,既可以做这个又可以做那个,它的内部依据某些变量和条件,来“选择”这个函数所要做的事情。比如,你也许写出这样的函数
~~~
void foo() {
if (getOS().equals("MacOS")) {
a();
} else {
b();
}
c();
if (getOS().equals("MacOS")) {
d();
} else {
e();
}
}
~~~
写这个函数的人,根据系统是否为“MacOS”来做不同的事情。你可以看出这个函数里,其实只有c()是两种系统共有的,而其它的a(), b(), d(), e()都属于不同的分支。
这种“复用”其实是有害的。如果一个函数可能做两种事情,它们之间共同点少于它们的不同点,那你最好就写两个不同的函数,否则这个函数的逻辑就不会很清晰,容易出现错误。其实,上面这个函数可以改写成两个函数:
~~~
void fooMacOS() {
a();
c();
d();
}
~~~
和
~~~
void fooOther() {
b();
c();
e();
}
~~~
如果你发现两件事情大部分内容相同,只有少数不同,多半时候你可以把相同的部分提取出去,做成一个辅助函数。比如,如果你有个函数是这样:
~~~
void foo() {
a();
b()
c();
if (getOS().equals("MacOS")) {
d();
} else {
e();
}
}
~~~
其中a(),b(),c()都是一样的,只有d()和e()根据系统有所不同。那么你可以把a(),b(),c()提取出去:
~~~
void preFoo() {
a();
b()
c();
~~~
然后制造两个函数:
~~~
void fooMacOS() {
preFoo();
d();
}
~~~
和
~~~
void fooOther() {
preFoo();
e();
}
~~~
这样一来,我们既共享了代码,又做到了每个函数只做一件简单的事情。这样的代码,逻辑就更加清晰。
* 避免使用全局变量和类成员(class member)来传递信息,尽量使用局部变量和参数。有些人写代码,经常用类成员来传递信息,就像这样:
~~~
class A {
String x;
void findX() {
...
x = ...;
}
void foo() {
findX();
...
print(x);
}
}
~~~
首先,他使用findX(),把一个值写入成员x。然后,使用x的值。这样,x就变成了findX和print之间的数据通道。由于x属于class A,这样程序就失去了模块化的结构。由于这两个函数依赖于成员x,它们不再有明确的输入和输出,而是依赖全局的数据。findX和foo不再能够离开class A而存在,而且由于类成员还有可能被其他代码改变,代码变得难以理解,难以确保正确性。
如果你使用局部变量而不是类成员来传递信息,那么这两个函数就不需要依赖于某一个class,而且更加容易理解,不易出错:
~~~
String findX() {
...
x = ...;
return x;
}
void foo() {
String x = findX();
print(x);
}
~~~
- 书列表
- laravel框架关键技术
- 第一章 组件化开发与composer使用
- 简介
- composer
- 添加路由组件
- 添加控制器模块
- 添加模型组件
- 添加视图组件
- 第三章 laravel框架中常用的php语法
- 匿名函数
- 文件包含
- 魔术方法
- 魔术常量
- 反射
- 后期静态绑定
- traits
- 第四章 laravel框架中使用的HTTP协议基础
- HTTP协议
- 数据库
- 数据迁移
- 第六章 laravel框架中的设计模式
- IOC模式
- php核心技术与最佳实践
- 第一章面向对象核心
- 反射
- 简单ORM
- 异常和错误
- 接口
- 第二章,面向对象设计
- 设计原则
- 单一职责
- 接口隔离
- 开放封闭
- 替换原则
- 依赖倒置
- linux是怎么写的呢?
- 第三章 正则表达
- 认识正则
- 第四章 php网络技术应用
- HTTP协议详解
- php和http相关函数
- 垃圾信息防御措施
- 现代操作系统
- 引论
- sql必知必会
- 限制结果
- 按位置排序
- where求职顺序
- IN操作符
- like
- 函数
- group by
- 组合查询
- 插入检索出的数据
- 视图
- 高性能mysql
- 第一章节 mysql架构与历史
- mysql架构逻辑图
- 连接与管理
- 优化与运行
- 读写锁
- 锁粒度
- 表锁(table lock)
- 行级锁(row lock)
- ACID
- 隔离级别
- 死锁
- 隐式和显式锁定
- 多版本并发控制
- Innodb概览
- 第四章节 Schema与数据类型优化
- 选择优化的数据类型
- 日期和时间类型
- 标识列
- 特殊类型数据
- 表设计中的缺陷
- 范式
- 计数器表
- 第五章 创建高性能索引
- 索引基础
- 索引类型
- 索引的优点
- 高性能索引策略
- 选择合适的索引列顺序
- 聚簇索引
- 顺序的主键什么时候会造成更坏的后果
- 覆盖索引
- 使用索引扫描来做排序
- 压缩索引
- 冗余和重复索引
- 索引和锁
- 支持多种过滤条件
- 什么是范围条件
- 优化排序
- 维护索引和表
- 表损坏
- 减少索引和数据的碎片
- 第六章 查询性能优化
- 扫描的行数和访问类型
- 重构查询方式
- 查询执行的基础
- 重构-改善既有代码设计
- 第一章-重构
- 什么是重构
- 第一个案列
- 重构第一步
- 王垠博客
- 多态取代价格相关逻辑