Function 哪一个特征对良好的日常生活最重要？

例程、过程、方法——不管你怎么称呼它们，它们都是我们开发人员的重要组成部分。您认为最重要的特征是什么

---

（通过为每个答案提供一个特征，可以单独投票给他们。也就是说，这个问题的目的不是要选出一个特征，而是突出所有重要的特征。）

它必须是原子代码行。

自评过程名称

示例： GetStoreFromAddress

---

GetCarsByMake

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

---

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

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

设计为便于人类阅读和理解-如果没有这些，它就很难修改它，使其具有这里列出的所有其他奇妙属性

---

如果这不完全是1，那么您可能有问题。

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

---

令人惊讶的是，函数X执行X和Y的频率是如此之高，或者执行X的大部分但不是全部。

在例程投入使用后，您应该跟踪所需的编辑次数。一个“好”的例程需要很少的编辑。一个“糟糕”的例程在需要大量修复的情况下肯定会被证明是如此

---

这可以通过在每次编辑后更新的每个方法调用上的注释头轻松完成 < P>它做了一件事或将多个事情委托给其他函数

清晰-易于理解

> P>我认为如果你把例程看作API的一部分，这更容易回答。独立的例程并不多，至少在一个真正有用的系统中是如此。坦白地说，我认为编写例程时要考虑的最重要的事情是：

直观性我的一套说明有多直观——人们不必费力阅读大量文档就能理解目的吗

正交性我的套路有多正交？每个人是否都完成一项特定任务，或者是否有多种（但略有不同）方法来完成同一件事？如果有，这是不好的，API可能需要重新设计

紧凑性完成简单任务需要多少API？我是否需要学习很多东西才能完成某件事，或者我只需要几套程序就能完成一些直观而强大的事情？您需要权衡这一点与正交性之间的权衡，以便为您的特定领域取得良好的平衡

---

通过例程名称，您可以说出例程的功能（当您检查代码时，您意识到您是对的；-）

没有一个标准可以区分好例程和坏例程

这些准则包括：

• 概念完整性：确实如此 可以用语言描述的事物 简单的简短形式，一句话或 段落
• 松耦合：其行为不受约束 对代码中发生的事情敏感 围绕着它
• 合理的大小：长的例程 更难阅读和理解，以及 不太可能有好的结果 概念完整性
• 帕纳斯的标准：他们“隐藏” 有一件事是可以改变的，那就是 需求变化有限 对系统其余部分的影响

---

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

它不应该有意外的副作用。

我要说的是，有充分的文件记录（并实际执行）的前置和后置条件。

简洁

---

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

一个返回点这是两个标准；-）我认为唯一的目的是最重要的。是的，我同意。一开始我甚至有过这样的经历：-）我在这里发现了一个引导性问题。。。你觉得怎么样？-1：我认为质量有几个方面，选择其中一个是没有帮助的。有“满足需求”、“性能”、“可维护性”、“适应性”和“拥有成本”，它们是正交的。举起一个似乎是个坏主意。你显然是对的！没有一个单一的特征足以成为一个好的常规。这个想法实际上是为了突出所有这些特征。所以你可以为他们每个人写一个答案，“所以你可以为他们每个人写一个答案”。这正是我所拒绝的，因为它不实用，甚至没有帮助。由于上下文定义了各种属性的相对排名，在一个特定的项目/问题领域之外没有可能的答案。s.Lott在我看来，你的思维水平与常规水平不同。大多数将好的常规与坏的常规区分开来的特征与你在第一次评论中提到的标准是正交的。例如，一个好名字或一个单一目的如何影响性能或拥有成本？那么你可以写四个答案，嗯？；）这意味着我同意一个单一的特征可以描述一个好的习惯。我没有，我不这么认为。在我看来，一次强调一个特征并不意味着我们相信任何一个特征就足够了。这仅仅是一种我们可以投票给我们认为重要的人的方法。你这个傻瓜！您违反了每个答案一个特征的规则！那很好。那么为什么不把它分成三个答案呢？也许我不应该回答b/c这个问题，我认为它过于简单了。我说很多次你不能在任何有意义的意义上考虑一个例行公事。这三个部分一起考虑模块或API中的所有例程。不过，感谢您的输入。你的观点很好！我反对