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

经过多年的积累，我发现以下基本指导原则可以支持我成为一名更高效的程序员。

【资料图】

编程规则与设计和工程原理密切相关。下面的编程规则赞助了我，让我受益匪浅，所以想和大家分享一下，希望赞助大家效率更高，产生的代码更容易保护，bug和缺点更少。

干燥原理

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

抽象原则

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

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

简单(避免复杂)应该始终被视为一个主要目的。写简短的代码不仅耗时少，错误少，而且容易纠正。

避免建立YAGNI(你不需要它)原则

只在需要的时候添加额外的效果，不需要的时候不要画蛇添足。

方法应该是最简单的，结果也应该是同样好的

编程时，我们需要问自己:“有没有最简单的方法来履行我们的义务？”这有助于我们坚持简单设计的道路。

不要让我想

这其实是史蒂夫·克鲁格写的一本书的书名。问题的关键是代码应该尽可能容易浏览和理解。如果访客需要大量深圳职业网的思维能力才能理解代码，那么也许这个代码需要简化。

开/关原理

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

为保护者写代码

值得写的代码应该保证将来值得保护。以后，因为你经历了太多的代码，再看这些代码的时候，你可能会和别人一样变成一个完全陌生的人。记住，“当你写代码的时候，假设你未来想要保护的人是一个暴力的能量病人，他知道你住在哪里。”

最小惊喜原则

用户界面方面通常引用最少惊喜的原则，但是这个原则也可以应用到代码编写中。代码应该尽量不要让观众感到惊讶。根据尺度协议，标注可以做到代码说什么就做什么，命名的意义是什么，尽可能避免惊喜带来的潜在负面影响。

单一责任原则

代码的组成部分(如类或函数)应该履行一个单一而明确的义务。

最小耦合原则

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

凝聚力最大化原则

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

隐蔽实施细节原则

隐藏实现细节，允许更改代码组件的实现，并最小化对应用组件的其他模块的影响。

德米特里定律

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

避免过早优化的原则

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

重用代码是好代码

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

关注分离原则

不同的功效领域应由代码模块管理，尽量减少明显的重叠。

接受变革的原则

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