We all use names for programming, it doesn’t matter if the language is high or low level, whether it is Imperative, Functional or Object Oriented. Names are everywhere. But we continue to misuse them. In this first part we will see how to find them.
我们都使用名称进行编程，无论语言是高级还是低级，无论是命令式，功能式还是面向对象。 名字无处不在。 但是我们继续滥用它们。 在第一部分中，我们将看到如何找到它们。
There are only two hard things in Computer Science: cache invalidation and naming things.
在计算机科学中只有两件难事：缓存无效和命名。
Phil Karlton
菲尔·卡尔顿
名字叫什么？ (What’s in a name?)
What’s in a name? That which we call a rose / By any other name would smell as sweet.
名字叫什么？ 我们所称的玫瑰/别的名字都会闻起来很甜。
William Shakespeare’s Romeo and Juliet.
威廉·莎士比亚的《罗密欧与朱丽叶》。
问题 (The Problem)
Code is read many more times than it is written. The first reads are done by the developer who chooses the names. Later, if the code survives, many other coders will make their own interpretations based on the footprints left by the nominator.
代码被读取的次数比其编写的次数多 。 初读由选择名称的开发人员完成。 以后，如果代码仍然存在，许多其他编码人员将根据提名者留下的足迹做出自己的解释。
Names are very important. They indicate the role that links the objects with their corresponding real entity in MAPPER.
名称非常重要。 它们指示在MAPPER中将对象与其对应的实际实体链接的角色。
Through this bijective relationship we will know who he is representing in the real world.
通过这种双向关系，我们将知道他在现实世界中的代表。
Names are created for human beings. Compilers don’t care about the name we assign to an object, class, variable, interface, trait, etc.
名称是为人类创建的。 编译器不在乎我们为对象，类，变量，接口，特征等分配的名称。
名字狂野 (Names are on the wild)
A single rule governs our designs:
一条规则支配我们的设计：
Always comply with the bijection of our MAPPER.
始终遵守我们的MAPPER的双射标准。
This is true in the particular case of names. When looking for a responsibility in the real world we will get the function name. then we will assign it to our objects in the computable model.
在名称的特定情况下，这是正确的。 在现实世界中寻找责任时，我们将获得函数名称。 然后将其分配给可计算模型中的对象。
情境为王 (Context is King)
All names are contextual. (Spoiler alert!)
所有名称均为上下文。 (扰流板警报！)
Darth Vader is Leia’s father.
达斯·维达(Darth Vader)是Leia的父亲 。
Leia is Kylo Ren’s mother.
Leia是Kylo Ren的母亲 。
Kylo Ren is Darth Vader’s grandson
凯洛·伦(Kylo Ren)是达斯·维达(Darth Vader)的孙子
The same person can be mother and daughter because they are roles. (more spoilers).
同一个人可以是母女，因为他们是角色。 (更多剧透)。
For Elizabeth, Charlotte is her mother (a role).
对于伊丽莎白来说，夏洛特是她的母亲 (一个角色)。
For Charlotte, Charlotte is her grandmother (one role).
对于夏洛特来说，夏洛特是她的祖母 (一个角色)。
There is a trend in the industry to name after the type (or class) of an object. This is a lousy decision that generates hidden assumptions and, therefore, coupling.
在行业中，以对象的类型(或类)命名的趋势是存在的。 这是一个糟糕的决定，会产生隐藏的假设 ，因此会产生耦合 。
These invisible decisions violate the principle of substitution and prevent polymorphism, by having coupled the name to the type we expect.
通过将名称与我们期望的类型耦合，这些无形的决定违反了替换原则并防止了多态性。
The fact that we are all human beings does not mean that there must be a variable $human referencing us.
我们都是人类这一事实并不意味着必须有一个变量$ human引用我们。
Rule 1: The role is contextual and temporary.
规则1：角色是上下文和临时的。
Corollary 1: We should not assign related names to the type or class.
结论1：我们不应为类型或类分配相关名称。
To name objects we have to think about the role they fulfill in the context in which they are being named (essential) and look beyond the type of physical entities (accidental).
要命名对象，我们必须考虑它们在被命名的上下文中所扮演的角色( 必不可少的 )，并且要超越物理实体的类型 ( 偶然的 )。
- 1 represents the natural number 1. 1代表自然数1。
- 3 represents the natural number 3. 3代表自然数3。
- 1/3 represents the fraction 1/3. 1/3代表分数1/3。
Being a numerator or denominator are roles. To be a proportion too. Never shall we use names such as fraction or integer (accidental) matching to the actual type. This concept is also called: intention revealing naming.
作为分子或分母是角色。 也要成比例。 切勿使用与实际类型匹配的分数或整数( 偶然的 )之类的名称。 这个概念也被称为： 意图揭示命名 。
空间就是极限 (The Space is the Limit)
Much of the current problems of software development are linked to ingrained habits that have no reason to exist today. Many of them associated with premature optimization. Nowadays there are developers who name variables saving space as if we were still in the 60s. The place allocated by a variable name does not influence the efficiency of the systems in any way today.
当前软件开发中的许多问题都与根深蒂固的习惯有关，而这些习惯如今已不存在。 其中许多与过早的优化有关 。 如今，有一些开发人员可以为变量命名，以节省空间，就像我们仍处于60年代一样。 如今，由变量名分配的位置不会以任何方式影响系统的效率。
Computer science was born from the mother of science (mathematics). In math, it is good practice to assign single letter variables (i, j, x, y).
计算机科学是从科学(数学)之母诞生的。 在数学中，分配单个字母变量(i，j，x，y)是一种好习惯。
The concept of reference arose from the variable.
参考的概念源自变量 。
It is time to emancipate ourselves, leave the maternal home and evolve.
现在是时候解放自己，离开产妇的家园并发展了。
Rule 2: Choose declarative names, sufficiently long but minimal
规则2：选择声明性名称，名称应足够长，但应最少
Corollary 2: The names of the variables must be composed of a sufficient number of words that uniquely distinguish the concept and role.
推论2：变量的名称必须由足够数量的单词组成，这些单词可以唯一地区分概念和角色。
If uniqueness is lost after removing any word, then the set is minimal.
如果删除任何单词后失去唯一性，则该集合最小。
缩短会产生耦合 (Shortening creates coupling)
My experience as a programmer began in the days of Ms-Dos. The file names were in 8.3 format:
我作为程序员的经验始于Ms-Dos时代。 文件名采用8.3格式：
8 letters for the name, 3 for the extension.
名称8个字母，扩展名3个字母。
Encoding file names in short space epochs was an art. There are heuristics such as: remove vowels, replace letters, etc.
在短时间段内编码文件名是一门艺术。 有启发式方法，例如：删除元音，替换字母等。
The program’s memory was extremely scarce and the variable maps allocation, as well as the source code, took up precious memory space.
程序的内存非常稀缺，变量映射分配以及源代码占用了宝贵的内存空间。
This is no longer the case. However, we spread bad habits to subsequent generations who behave like sprayed monkeys, maintaining a terrible habit only by inertia.
这已不再是这种情况。 但是，我们向后代散布了坏习惯，这些行为举止像喷洒的猴子，仅靠惯性就能维持可怕的习惯。
If we abbreviate the names, we generate a link with that shortcut (which is not bijective) and another link between the name and its abbreviation.
如果我们缩写名称，则会生成一个具有该快捷方式的链接(该链接不是双向的)，以及名称和缩写之间的另一个链接。
i = 1
我= 1
The variable i: does it represent an index? An iterator? Or an integer?
变量i：它代表索引吗？ 迭代器？ 还是整数？
What role does this reference play? In what decade was it programmed?
此参考文件起什么作用？ 在哪个十年中编程过？
Abbreviating creates unnecessary indirection and breaks bijection. The same abbreviation could want to refer to two different objects.
缩写会产生不必要的间接并打破双射。 相同的缩写可能要引用两个不同的对象。
The decision about which one represents is coupled and generates ripple effect.
代表哪个代表的决定会产生连锁React。
Rule 3: Names will generally be long.
规则3：名称通常会很长。
如有疑问，将无意义的名称 (When in doubt, a meaningless name would to it)
If we are not mature enough on studying the model to find the appropriate name in the bijection, we must give it a really annoying name.
如果我们在研究模型时还不够成熟，无法在双射中找到合适的名称，则必须给它起一个非常烦人的名称。
A mediocre name will stay forever until a responsible developer takes courage and refactoring it.
一个平庸的名字将永远存在，直到负责任的开发人员鼓起勇气并对其进行重构为止。
A lousy name cries out to be recognized as a technical debt and to reflect.
一个糟糕的名字被呼唤为技术债务并得到反映。
Rule 4: Faced with incomplete knowledge, put bad names.
规则4：面对不完整的知识，请放下恶名。
坏名字要求重构 (Bad names ask for refactor)
It is extremely difficult to modify a system while keeping bad names.
在保留坏名的同时修改系统非常困难。
For example, this is a piece of code that is used in job interviews in order to find a mistake.
例如，这是在工作面试中用来发现错误的一段代码。
The first step to tackle this problem is understanding what do the variables represent. After a good naming finding the error is much easier.
解决此问题的第一步是了解变量代表什么。 经过良好的命名后，发现错误要容易得多。
A lousy name is there, annoying, drawing attention and making us reflect on a necessary change.
一个糟糕的名字在那里，令人讨厌，引起了人们的注意，并使我们思考必要的改变。
A bad name gives us a false sense of having a mature concept.
不好的名字使我们误以为拥有成熟的概念。
There is nothing worse than a bad abstraction carved in stone.
没有比刻在石头上的糟糕抽象更糟糕的了。
Rule 5: Modify bad names only when we know enough about the domain.
规则5：仅当我们对域名了解得足够多时，才可以修改坏名。
一个好名字是我们要学习的最后一件事 (A good name is the last thing we will learn)
The Wittgensteinian school of thought teaches us that human beings learn to generalize from a few examples.
维特根斯坦思想流派告诉我们，人类可以通过一些例子来进行概括。
The brain power to create abstractions is incredible.
创建抽象的脑力是不可思议的。
Programmers tend to go further and try to generalize from a single example. Making an analogy with biology, it would be like defining mammal after meeting the first lion.
程序员倾向于走得更远，并尝试从一个示例中进行概括。 用生物学做一个比喻，就像遇到第一只狮子后定义哺乳动物。
Nowadays, IDEs go even further and ask us to generalize without having built any examples, by forcing us to name a class without having known yet any instance or having defined its responsibilities.
如今，IDE甚至走得更远，要求我们在不构建任何示例的情况下进行概括，即强迫我们在不知道任何实例或定义其职责的情况下命名一个类。
Generalizing takes observation time, flight hours and concepts maturing.
概括需要观察时间，飞行时间和概念的成熟。
The Aristotelian classification is made after a detailed observation of multiple cases, so …
亚里士多德分类是在对多个案例进行了详细观察之后做出的，因此…
What are we programmers doing? Why do we insist on generalizing early in our process?
我们程序员在做什么？ 为什么我们坚持在过程的早期进行概括？
The accidental and historical reason is linked to the first code editors, who forced us to define the names first in order to build models.
偶然的和历史的原因与第一个代码编辑器相关，后者迫使我们首先定义名称以构建模型。
Today we have powerful secure refactoring tools.
今天，我们拥有功能强大的安全重构工具。
An anti-pattern would be to keep the same name that we defined the first time we elaborated a concept.
一种反模式是保持与我们首次阐述概念时定义的名称相同。
Rule 6: Never name a class before assigning responsibilities.
规则6：在分配职责之前，请勿命名课程。
没意见 (No comments)
Writing comments is a code smell indicating that a method, name, variable etc. it is not very declarative.
编写注释是一种代码味道，表明方法，名称，变量等不是很声明。
If we can write incredibly descriptive names, we will avoid having to maintain “clarifying” comments that do not add value and are linked to accidental decisions and hardly maintained.
如果我们可以写出令人难以置信的描述性名称，我们将避免维护“澄清”的注释，这些注释不会增加价值，并且与意外的决定相关并且很难维护。
Rule 7: Avoid comments.
规则7：避免发表评论。
领域专家积累知识 (Domain experts build knowledge)
As a final rule and, contradicting these rigid rules, we must understand that a good name is the product of a mature knowledge of the problem domain.
作为最终规则，并且与这些严格的规则相矛盾，我们必须理解，好名声是对问题域的成熟知识的产物。
Rule 8: Perfect names arise over time.
规则8：完美的名字随着时间的流逝而出现。
玻璃杯已满 (The glass is half full)
Technology advances and helps us to correct all the vices described above.
技术进步并帮助我们纠正了上述所有弊端。
Today we have powerful linters in almost all modern languages, which help us to enforce and enforce these design rules.
今天，我们拥有几乎所有现代语言的功能强大的lint ，可帮助我们强制执行这些设计规则。
We just need to tackle the damage already done and build better solutions.
我们只需要解决已经造成的损害并建立更好的解决方案。
In a future article we will focus on a series of current bad practices explaining with arguments which ingrained uses we should modify.
在以后的文章中，我们将重点介绍一系列当前的不良做法，并用我们应该修改的根深蒂固的用法来解释。
规则摘要(到目前为止) (Rules Summary (so far))
- Names must be declarative and not implementing. 名称必须是声明性的，不能实现。
- Names must be contextual. 名称必须是上下文的。
- Do not mix type with role. 不要将角色与类型混在一起。
- Assign responsibilities before assigning names. 在分配名称之前，先分配职责。
- When in doubt, put bad names. 如有疑问，请贴上恶名。
Avoid comments.
避免发表评论 。
结论 (Conclusions)
Giving good names is an art that requires a deep understanding of the problem domain we are modeling. We must not underestimate this task.
给出好名字是一门艺术，需要深刻理解我们正在建模的问题领域。 我们决不能低估这项任务。
Let’s remember the quote:
让我们记住报价：
Always program as if the person who will end up keeping our code is a violent psychopath who knows where we live. John Woods.
始终编程，就像最终将遵守我们代码的人是知道我们住在哪里的暴力精神病患者一样。 约翰·伍兹。
Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.
本系列文章的目的之一是为软件设计的辩论和讨论创造空间。
We look forward to comments and suggestions on this article.
我们期待对本文的评论和建议。
Hit me up on Twitter @mcsee1 :)
在Twitter @ mcsee1上打我
This article is also available in Spanish here.
本文也可以在西班牙语中找到 。
翻译自: https://medium.com/dev-genius/what-exactly-is-a-name-part-i-the-quest-b812a4b1e0bf
8720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
