优秀的编程原则

英文原文:Principles of Good Programming

避免重复原则 DRY – Don’t repeat yourself

编程的最基本原则是避免重复。在程序代码中总会有很多结构体,如循环、函数、类等等。一旦你重复某个语句或概念,就应该考虑做一下抽象了。

抽象原则 Abstraction Principle

抽象原则也和 DRY 原则有关,程序代码中每一个重要的功能,只能出现在源代码的一个位置。

简单原则 KISS (Keep it simple, stupid!)

简单是软件设计的目标,简单的代码占用时间少,漏洞少,并且易于修改

避免创建你不需要的代码 Avoid Creating a YAGNI (You aren’t going to need it)

除非你需要它,否则别创建新功能

用最简单的方式解决问题 Do the simplest thing that could possibly work

尽可能做可行的最简单的事。在编程中,一定要保持简单原则。作为一名程序员不断的反思“如何在工作中做到简化呢?”这将有利于设计方案的简洁明了。

不要让我思考 Don’t make me think

这是Steve Krug一本书的标题,同时也和编程有关。所编写的代码一定要易于读易于理解,这样别人才会欣赏,也能够给你提出合理化的建议。相反,若是繁杂难解的程序,其他人总是会避而远之的

开闭原则 Open/Closed Principle

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

写易维护的代码 Write Code for the Maintainer

几乎所有代码都是需要长期维护的,不管是你自己维护还是别人维护。即使是自己的代码,一段时间以后自己也可能忘记里面的逻辑,所以相当于写代码的人和维护的人不是同一个。一个优秀的代码,应当使本人或是他人在将来都能够对它继续编写或维护。代码维护时,或许本人会比较容易,但对他人却比较麻烦。因此你写的代码要尽可能保证他人能够容易维护。用书中原话说“如果一个维护者不再继续维护你的代码,很可能他就有想杀了你的冲动。”

最小惊讶原则 Principle of least astonishment

最小惊讶原则通常是在用户界面方面引用,但同样适用于编写的代码。代码应该尽可能减少让读者惊讶(代码不应该误导阅读者)。也就是说,你编写的代码只需按照项目的要求来编写。其他华丽的功能就不必了,以免弄巧成拙。比如注释的说明要和代码一致,函数名要和函数内容一致,要避免迷惑和误导。

单一职责原则Single Responsibility Principle

一段代码(类或函数)应只实现一个单一的明确的任务。

低耦合Minimize Coupling

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

高内聚 Maximize Cohesion

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

隐藏实现细节 Hide Implementation Details

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

迪米特法则又叫最少知识原则 Law of Demeter

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

避免过早优化 Avoid Premature Optimization

除非你的代码运行的比你想像中的要慢,否则别去优化。假如你真的想优化,就必须先想好如何用数据证明,它的速度变快了。

“过早的优化是一切罪恶的根源”——Donald Knuth

代码复用 Code Reuse is Good

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

关注点分离 Separation of Concerns

不同领域的功能,应该由不同的代码和最小重迭的模块组成

拥抱变化 Embrace Change

许多其他原则都是基于这个概念的,即你应该积极面对变化。事实上,一些较老的编程原则如最小化耦合原则都是为了使代码能够容易变化。无论你是否是个极限编程者,基于这个原则去编写代码会让你的工作变得更有意义

 

参考:

https://github.com/Dongss/principles-of-good-programming-cn

http://blog.sina.com.cn/s/blog_627839ac0100uq6d.html

 

此条目发表在设计分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注