对于一个好的例程，哪个单一特征最重要？

Question

例程，程序，方法 - 无论你怎么称呼它们，它们都是我们开发人员的重要组成部分。您评价最重要的一个特征是什么？

（通过为每个答案提供一个特征，可以单独投票。也就是说，这个问题的目的不是决定挑出一个特征，而是强调所有重要的。）

Answer 1

我认为最重要的标准是它有一个目的。

之后，它正确地满足了这个目的（并且只有那个目的）。

Answer 2

自评程序名称。

实施例： GetStoreFromAddress GetCarsByMake

Answer 3

它应该很容易进行单元测试。

Answer 4

例程的名称一对一映射到它的功能。

令人惊讶的是，函数X经常X和X，或X的大部分而不是X的全部。

Answer 5

没有单一的标准来区分好的例程和坏例程。

中的标准是：

• 概念完整性：确实如此 一些可以描述的东西 简单的简短形式，一句话或 段;
• 松耦合：它的行为不是 对代码中发生的事情很敏感 围绕它;
• 合理的尺寸：长的例程 更难阅读和理解，和 不太可能有好处 概念完整性;
• Parnas的标准：他们“隐藏” 有一件事可以改变，所以 要求变化有限 对系统其他部分的影响。

Answer 6

旨在让人们轻松阅读和理解 - 如果不是这样，修改它以获得将在此处列出的所有其他精彩属性更加困难

Answer 7

尝试做的事情。

如果这不是1，那么你可能有问题。

Answer 8

它不应该有意想不到的副作用。

Answer 9

简洁

（这应该是一个半有趣的答案，但是不要让它自己发布单词！）

Answer 10

良好的错误处理（可靠性）

Answer 11

代码行。

Answer 12

我会说有很好的记录（并且实际强制执行）前后条件。

Answer 13

该例程始终使用一致的抽象级别。

Answer 14

从例程名称，您可以说出例程的作用（当您检查代码时，您意识到您是对的; - ）

Answer 15

如果您将例程视为API的一部分，我认为这更容易解答。没有多少例程是独立的，至少不是真正有用的系统。老实说，我认为在编写例程时要考虑的最重要的事情是：

1. 直觉性我的说明书是多么直观 - 人们是否能够理解目的而无需通过大量文档？

2. Orthogonality 我的例程如何正交？每个完成一项特定任务，还是有多种（但略有不同）的方法来做同样的事情？如果有，这很糟糕，API可能需要重新设计。

3. 紧凑性完成简单任务需要多少API？我是否需要学习很多东西才能完成某些工作，或者我只需要做一些直观而强大的例程即可满足要求？你需要权衡这个与正交性的权衡，以便为你的特定领域取得良好的平衡。

Answer 16

清晰度 - 易于理解

Answer 17

它做一件事或将多件事委托给其他职能

Answer 18

您应该跟踪例程投入使用后所需的编辑次数。 “好”例程是需要很少编辑的例程。当需要一堆修复时，一个“坏”例程肯定会证明是这样的。

这可以通过在每次编辑后更新的每个方法调用上的注释标题轻松完成。

Answer 19

必须是原子的

Answer 20

单个返回点