Skip to content

Dongss/principles-of-good-programming-cn

master
Switch branches/tags
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 

优秀的编程原则

翻译自: Principles of Good Programming

DRY - Don’t repeat yourself

不要重复自己

这大概是编程最基本的原则。也由此产生了很多编程的概念(比如循环,函数,类,等等)。一旦我们开始重复自己,就应该考虑做一下抽象了。

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle

抽象原则

抽象原则也和 DRY 原则有关,“程序中的每段核心功能代码应该只在源代码中的一个地方实现”。

http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!)

代码简洁

代码简洁是一个很重要的目标,写简洁的代码耗费的时间更少、bug 更少、更易于修改。

http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it)

如果某个功能你还用不到,就不要去实现它。

http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work

用最简单的方式解决问题

时常问自己“能解决问题(完成需求)的最简单的方式是什么?”,有利于设计方案的简洁明了。

http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think

不要让我思考

这正是 Steve Krug 的一本关于 web 可用性的书的标题,同样适用于编程。代码应该保持简洁易读,如果读起来太过复杂,应该简化一下。

http://www.sensible.com/dmmt.html

Open/Closed Principle

开闭原则

软件功能(类,模块,函数等等)应对拓展开放,对修改封闭。换句话说,不要写需要别人修改的类,要写便于别人拓展的类。

http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer

写易维护的代码

几乎所有代码都是需要长期维护的,不管是你自己维护还是别人维护。即使是自己的代码,一段时间以后自己也可能忘记里面的逻辑,所以相当于写代码的人和维护的人不是同一个。有这么个方法“写代码的时候记着,将来维护代码的人是一个知道你住在哪里的变态暴力狂”。

http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment

减少误导

这个原则通常在接口上被提到,但在代码里也很重要,代码不应该误导阅读者。注释的说明要和代码一致,函数名要和函数内容一致,要避免迷惑和误导。

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle

单一功能原则

一段代码(类或函数)应只实现一个单一的定义清晰的任务。

http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling

低耦合

代码的任何部分(代码块,函数,类等等)都应该减少对其他部分代码的依赖,要尽量减少变量共享。“低耦合通常是结构优秀的计算机系统和好的设计的标志,配合高内聚,就能实现高可读和易维护的目标”。

http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion

高内聚

实现一个功能相关的代码,都应在同一个模块中实现。

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details

隐藏实现细节

隐藏实现细节,当内部逻辑修改时,能够减少对其他使用者的影响。

http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter

迪米特法则

代码应该跟有直接关联的部分交互(比如类继承的父类、包含的对象、传入的参数,等等)。

http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization

避免过早优化

代码还在正常工作的时候不必考虑优化,除非运行速度不及预期,并且最好在有量化数据对比的前提下进行。“我们应忽略小的影响,大约97%的情况下:过早优化是万恶之源” -- Donald Knuth。

http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good

代码复用

代码复用可以提高代码可用性并减少开发时间。

http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns

关注分离

不同的功能应分开管理并有明显界限,要最大程度降低模块间代码的重叠。

http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change

拥抱变化

这是 Kent Beck 一本书的子题目,也是极限编程和敏捷开发的一个宗旨。很多其他的原则都是基于期望并拥抱变化的初心,一些传统的软件工程原则比如“低耦合”都有利于更简单的修改代码。不管你是不是极限编程爱好者,这个原则对写代码都很有帮助。

http://www.amazon.com/gp/product/0321278658

About

优秀的编程原则(译)

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published