程序员法则(优秀程序员的18条法则)

经过多年的积累，我发现以下基本准则可以帮助我成为一名更高效的程序员。

编程规则与设计和工程原理密切相关。以下编程规则帮助我受益匪浅，所以想和大家分享一下。希望它们能帮助你更高效，代码更容易维护，bug和缺陷更少。

干燥原理

不要重复自己——编程中最基本的原则之一就是避免重复。许多编程结构(如循环、函数、类等。)的存在是为了避免重复。一旦重复(例如，一个长表达式，一系列语句，同一个概念)，就会产生一个新的抽象。

抽象原则

“程序中每一个有意义的功能片段都应该只在源代码的一个地方实现。”

吻(保持简单，笨蛋！)原则

简单(避免复杂)应该永远被视为一个重要的目标。编写简单的代码不仅耗时少，错误少，而且易于修改。

避免创造yagni(你会需要它)原则。

仅在需要时添加额外功能。如果你不需要它们，就不要画蛇添足。

方法应该是最简单的，效果应该一样好。

编程时，我们需要问自己:“有没有最简单的方法来完成任务？”这有助于我们继续走在简约设计的道路上。

不要让我思考。

这实际上是史蒂夫·克鲁格写的一本书的标题。关键是代码要尽可能的易读易懂。如果读者需要大量的思考来理解代码，那么也许代码需要被简化。

开/关原理

软件实体(类、模块、函数等。)展开时应该打开，修改时应该关闭。换句话说，你写的类可以扩展，但不能修改。

给维护人员写代码。

值得写的代码要保证将来值得维护。以后因为经历了太多代码，也许当你回头看代码的时候，你和别人一样，已经变成了一个完全陌生的人。记住，“写代码的时候，假设你未来要维护的人是一个知道你住哪儿的暴力神经病。”

最小惊奇原则

最小惊奇原则通常适用于用户界面，但也适用于代码编写。代码应该尽可能不让读者感到惊讶。遵守标准协议，对代码按照注释说的去做，名字的意思就是代码的意思，尽量避免惊喜带来的潜在负面影响。

单一责任原则

代码的组成部分(例如类或函数的信息资源的数量)应该执行一个单一且清晰的任务。

最小耦合原理

代码的任何部分(代码块、函数、类等)。)应该尽量减少对其他代码的依赖。这可以通过尽量不使用共享变量来实现。“低耦合往往是构造良好的和设计良好的计算机系统的标志，当与高内聚结合时，它可以极大地支持高可读性和可维护性的总体目标。”

凝聚力最大化原则

功能相似的代码应该放在同一个组件中。

隐藏实现细节的原则

隐藏详细实现允许改变代码组件的实现，同时最小化对使用该组件的其他模块的影响。

德米特里定律

组件应该只与它们的直接关系(比如继承的类、包含的对象、通过参数传递的对象等)进行通信。).

避免过早优化的原则

除非代码开始工作，否则不要考虑优化。只有在不得不优化的时候，才能借助实战数据。“我们必须有一个大的图景:过早的优化是万恶之源”——唐纳德·克努特。

重用代码是好代码。

这和其他任何法律一样精辟。代码重用可以提高代码的可靠性，减少开发时间。

关注点分离原则

的不同功能区域应由代码模块管理，明显的重叠最小。

接受变革的原则

这是Kent Beck写的一本书的副标题，也被认为是极限编程和通用敏捷方法的原理。许多其他原则都是基于这个想法:你应该期待并欢迎变化。事实上，许多古老的软件工程原则，如最小化耦合原则，都与使代码更容易更改直接相关。不管你是不是极限编程从业者，这种写代码的方法真的很有意义。