提起程序员法则（优秀程序员的18大法则） 大家在熟悉不过了，被越来越多的人所熟知，那你知道程序员法则（优秀程序员的18大法则） 吗？快和小编一起去了解一下吧！
(相关资料图)
程序员规则(优秀程序员的18条规则)
经过多年的积累，我发现以下基本准则可以帮助我成为一名更高效的程序员。
程序设计规则与设计和工程原理密切相关。以下编程规则，帮助我受益匪浅，想分享给大家。我希望它们也能帮助你更有效率。产生的代码更容易维护，bug和缺陷更少。
干燥原理
不要重复自己——编程中最基本的原则之一就是避免重复。许多编程结构(如循环、函数、类等。)的存在是为了避免重复。一旦重复(例如，一个长表达式，一系列语句，同一个概念)，就会产生一个新的抽象。
抽象原则
“程序中每一个有意义的功能片段都应该只在源代码的一个地方实现。”
吻(保持简单，笨蛋！)原则
简单(避免复杂)应该永远被视为一个重要的目标。编写简单的代码不仅耗时少，错误少，而且易于修改。
避免YAGNI(你不会需要它)原则。
只有在需要的时候，才可以添加附加功能。不需要就不要画蛇添足。
方法应该是最简单的，效果应该一样好。
编程时，我们需要问自己:“有没有最简单的方法来完成任务？”这有助于我们继续走简单设计的道路。
不要让我思考。
这实际上是史蒂夫·克鲁格写的一本书的标题。关键是代码要尽可能的易读易懂。如果读者需要大量的思考来理解代码，那么也许代码需要简化。
开/关原理
软件实体(类、模块、函数等。)应该在扩展时打开，在修改时关闭。换句话说，您的类可以扩展，但不能修改。
给维护人员写代码。
值得写的代码要保证将来值得维护。以后因为经历了太多的代码，当你回头看这些代码的时候，你可能会和别人一样，变成一个完全陌生的人。记住，“写代码的时候，假设未来要维护的人是知道你住哪儿的暴力神经病。友资源网”
最小惊讶原则
最小惊奇原则通常用于用户界面，但也适用于代码编写。尽可能地，代码不应该让读者感到惊讶。遵守标准约定，按评论里代码说的做，名字的意思就是代码的意思，尽量避免惊喜带来的潜在负面影响。
单一责任原则
代码的组件(比如类或函数)应该执行一个单一且明确的任务。
最小耦合原理
代码的任何部分(代码块、函数、类等。)应该尽量减少对其他代码的依赖。这可以通过尽量不使用共享变量来实现。“低耦合通常是构造良好和设计良好的计算机系统的标志，当与高内聚结合时，它还可以极大地支持高可读性和可维护性的总体目标。”
更大凝聚力原则
功能相似的代码应该放在同一个组件中。
隐藏细节原则
隐藏实现细节允许您更改代码组件的实现，同时最小化对使用该组件的其他模块的影响。
德米特里定律
组件应该只与它们的直接关系(例如，继承的类、包含的对象、通过参数传递的对象等)进行通信。).
避免过早优化的原则
除非代码开始工作，否则不要考虑优化。只有在不得不优化的时候，才能借助实战数据。“我们必须有一个大的图景:过早的优化是万恶之源”——唐纳德·克努特。
代码重用是好代码。
这和其他法律一样精彩。代码重用可以提高代码的可靠性，减少开发时间。
关注点分离原则
不同的功能区域应该由明显重叠最小的代码模块来管理。
接受变革的原则
这是肯特·贝克写的一本书的副标题。它也被认为是极限编程和一般敏捷方法的原则。许多其他原则都是基于这个想法:你应该期待并欢迎变化。事实上，许多古老的软件工程原则，如最小化耦合原则，都与使代码更容易更改直接相关。不管你是不是极限编程从业者，这种写代码的方法真的很有意义。
