What Exactly Is A Name: The Quest [Part I]

We all agree: a good name is always the most important thing. Let’s find them. 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? William Shakespeare’s Romeo and Juliet. What’s in a name? That which we call a rose / By any other name would smell as sweet. - Photo by Evie Fjord on Unsplash The Problem Code is read many . 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. more times than it is written Names are very important. They indicate the role that links the objects with their corresponding real entity in . MAPPER What is (wrong with) software? Through this relationship we will know who he is representing in the real world. bijective The One and Only Software Design Principle Names are created for human beings. Compilers don’t care about the name we assign to an object, class, variable, interface, trait, etc. Photo by Erhan Astam on Unsplash Names are on the wild A single rule governs our designs: Always comply with the bijection of our 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 Star Wars model All names are contextual. (Spoiler alert!) Darth Vader is Leia’s . father Leia is Kylo Ren’s . mother Kylo Ren is Darth Vader’s grandson Dark model The same person can be mother and daughter because they are roles. (more spoilers). For Charlotte, Elizabeth is her (a role). mother For Elizabeth, Charlotte is her (a role). mother For Charlotte, Charlotte is her (a role). grandmother There is a trend in the industry to name after the type (or class) of an object. This is a lousy decision that generates and, therefore, . hidden assumptions coupling These invisible decisions violate the principle of substitution and prevent polymorphism, by having coupled the name to the type we expect. Coupling: The One and Only Software Designing Problem The fact that we are all human beings does not mean that there must be a variable referencing us. $human Rule 1: The role is contextual and temporary. Corollary 1: We should not assign related names to the type or class. To name objects we have to think about the role they fulfill in the context in which they are being named ( ) and look beyond the of physical entities ( ). essential type accidental 1 represents the natural number 1 3 represents the natural number 3. 1/3 represents the fraction 1/3. Being a numerator or denominator are roles. To be a proportion too. Never shall we use names such as fraction or integer ( ) matching to the actual type. This concept is also called: . accidental 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. 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). The concept of arose from the . reference variable Many people wondered and computer scientists cannot. why mathematicians can work with such short variables For mathematicians, once entered into a formula, variables lose all semantics and become indistinguishable. It is time to emancipate ourselves, leave the maternal home and evolve. Photo by Pablo Heimplatz on Unsplash Rule 2: Choose declarative names, sufficiently long but minimal Corollary 2: The names of the variables must be composed of a sufficient number of words that uniquely distinguish the concept and role. 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: 8 letters for the name, 3 for the extension. Encoding file names in short space epochs was an art. There are heuristics such as: remove vowels, replace letters, etc. Norton Commander 5 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 The variable : does it represent an index? An iterator? Or an integer? i Bijection breaks with abbreviations What role does this reference play? In what decade was it programmed? Abbreviating creates indirection and breaks bijection. The same abbreviation could want to refer to two different objects. unnecessary The decision about which one represents is coupled and generates ripple effect. Rule 3: Names will generally be long. 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. Bad names ask for refactor It is extremely difficult to modify a system while keeping bad names. How to Decouple a Legacy System 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, , drawing attention and making us reflect on a necessary change. annoying us 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. 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 examples, by forcing us to name a class without having known instance or having defined its responsibilities. any any 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 would be to keep the same name that we defined the first time we elaborated a concept. anti-pattern Rule 6: Never name a class before assigning responsibilities. No comments Writing comments is a indicating that a method, name, variable etc. it is not very declarative. code smell 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. 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. The glass is half full Technology advances and helps us to correct all the vices described above. Today we have powerful in almost all modern languages, which help us to enforce and enforce these design rules. linters We just need to take on the damage already done and build better solutions. In a the following article we focus on a series of current bad practices explaining with arguments which ingrained uses we should modify. What Exactly Is A Name: Rehab [Part II] 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