对于良好的日常习惯来说，哪一个特征最重要？
例程、过程、方法——无论你怎么称呼它们，它们对于我们开发人员来说都是重要的构建块。 您将哪一项特征视为最重要？
（通过为每个答案提供一个特征，可以单独投票给它们。即，这个问题的目的不是决定挑出一个特征，而是突出所有重要的特征。 ）
Routines, procedures, methods - whatever you call them, they are important building blocks for us developers. What single characteristic would you rate as the most important one?
(By providing one characteristic per answer, it is possible to vote for them individually. I.e. the purpose of this question is not to decide single out one characteristic, but rather, to highlight all of the important ones.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（20）
我认为最重要的标准是它具有单一目的。
之后，它正确地满足了该目的（并且仅满足了该目的）。
I think the most important criteria would be that it has a single purpose.
After that, that it satisfies that purpose (and only that purpose) correctly.
自我注释过程名称。
例子：
获取商店地址
按品牌获取汽车
Self Commenting Procedure Names.
Examples:
GetStoreFromAddress
GetCarsByMake
它应该很容易进行单元测试。
It should be easily unit tested.
例程的名称与其功能一一对应。
令人惊讶的是，函数 X 执行 X 和 Y，或者执行大部分 X 但不是全部 X 的频率。
The routine's name maps one to one to it's functionality.
It's surprising how often a function X does X and also Y, or most of X but not all of X.
没有任何单一的标准可以区分好习惯和坏习惯。
其中标准包括：
可以描述的东西
简单的简短形式，一句话或
段落;
对代码中发生的事情敏感
周围;
更难阅读和理解，并且
不太可能拥有好的
概念完整性；
有一件事可以改变，所以
需求变化有限
对系统其余部分的影响。
There is no single criterion that distinguishes a good routine from a bad one.
Among the criteria are:
something that can be described in a
simple short form, one sentence or
paragraph;
sensitive to what goes on in code
around it;
harder to read and understand, and
are less likely to have good
conceptual integrity;
one thing that can change, so that
requirements changes have limited
effect on the rest of the system.
设计为易于人类阅读和理解 - 如果没有它，修改它以具有此处列出的所有其他精彩属性会困难得多
designed to be easily read and understood by humans - without that in place it is much harder to modify it to have all of the other wonderful attributes that will be listed here
它尝试做的事情的数量。
如果这不完全是 1 那么你可能有问题。
Number of things it tries to do.
If this isn't exactly 1 then you probably have a problem.
它不应该有意想不到的副作用。
It shouldn't have unexpected side-effects.
良好的错误处理能力（可靠性）
good error handling (reliability)
简洁
（这应该是一个半有趣的答案，但所以不会让单独发布这个单词！）
brevity
(this was supposed to be a semi-fun answer, but SO wouldn't let be post the single word on its own!)
它必须是原子的
It has to be atomic
代码行。
Lines of code.
您应该跟踪例程投入使用后所需的编辑次数。 “好的”例程是需要很少编辑的例程。 当需要进行大量修复时，“糟糕”的例程肯定会证明自己是这样。
这可以通过每次编辑后更新的每个方法调用上的注释标题轻松完成。
You should track the number of edits required after the routine was put into use. A 'good' routine is one with few edits required. A 'bad' routine definitely proves itself to be so when there are a bunch of fixes required.
This can easily be accomplished with a comment header on each method call that gets updated after each edit.
它做一件事或将多件事委托给其他功能
It does one thing or delegates multiple things to other functions
清晰 - 易于理解
Clarity - Easy to understand
我认为如果您将例程视为 API 的一部分，这个问题就更容易回答。 独立的例程并不多，至少在真正有用的系统中是这样。 老实说，我认为编写例程时要考虑的最重要的事情是：
直观性我的指令集有多直观 - 人们无需费力阅读大量文档即可理解其目的？
正交性 我的例程的正交性如何？ 每个人都完成一项特定的任务，还是有多种（但略有不同）的方法来完成同一件事？ 如果有，那就很糟糕，API 可能需要重新设计。
紧凑性需要多少 API 才能完成简单的任务？ 我是否需要学习很多东西才能完成某件事，或者我只需要几个可以做一些直观且强大的事情的例程就足够了？ 您需要权衡这一点与正交性的权衡，以便为您的特定领域取得良好的平衡。
I think this is more easily answered if you consider routines as part of an API. There aren't many routines that stand alone, at least not in a truly useful system. So honestly, I think the most important things to consider when writing routines are:
Intuitiveness How intuitive is my set of instructions -- will people understand the purpose without having to wade through a lot of documentation?
Orthogonality How orthogonal are my routines? Does each accomplish one particular task, or are there multiple (but slightly different) ways to do the same thing? If there are, this is bad, and the API probably needs to be redesigned.
Compactness How much of the API does it take to get simple tasks done? Do I need to learn a lot of stuff to get something done, or can I suffice with just a couple routines that do something intuitive and powerful? You need to weigh the tradeoffs of this one with orthogonality to strike a good balance for your particular domain.
从例程名称中，您可以说出该例程的作用（当您检查代码时，您会意识到您是对的；-）
From the routine name, you can say what the routine does (and when you check the code, you realize that you were right ;-)
该例程自始至终都使用一致的抽象级别。
The routine uses a consistent level of abstraction throughout.
我想说的是有据可查（并且实际上执行）的前置条件和后置条件。
I would say well documented (and actually enforced) pre and post conditions.
单一返回点
A single return point