To become a programmer is to sign up for a lifelong training. The stream of new - new features, new languages, new tools, new frameworks - never runs dry. But at the same time, programming is a sphere, surprisingly faithful to traditions, where everything is based on principles tested by time. We introduced object-oriented programming, modern hardware solutions, artificial intelligence, however, despite all these changes, many of the axioms that were formulated in the previous generation turn out to be true today.I devoted this article to a few of my favorite statements about programming. The only criterion by which I made the selection was the requirement that the quote be equal to at least twenty years. Because it is only obsolete technologies that quickly become unusable, while the ancient commandments of our ancestor programmers have long remained relevant.1. Indirectness
“All programming problems are solved by creating an additional level of indirection” - David Willer
Here is a quote from the book Computer Science Theory and Application, which everyone likes to repeat and few people like to explain. Nevertheless, this is one of my favorite programming truths - it aptly reveals the very essence of programming.The easiest way to make sense of indirection is to imagine layers. Well, for example, imagine that you have a small project in which you need to place component A inside component B:Both components are standardized, so disassembling them into components and changing the principle of operation will not work. You could create a separate add-on component ( PlugTwoProngVariant), but this is both a lot of work and unnecessary duplication. There is a better solution: add an adapter layer between these two components that successfully interacts with both and serves as an intermediary between them.With all this, if the indirection was exhausted by the addition of additional layers between components that would not otherwise dock, it would, of course, be useful, but very limited in application. But the very idea of ​​solving problems by changing the environment of problem areas permeates all programming from top to bottom. You encounter it when you try to fit a new data model to the old interface. You encounter it when you try to attach an application with legacy code to the backend of a new web service. You encounter it when you need to add several new high-level functions like logging and caching or coordinate the work of several high-level services like sending messages and conducting transactions.At the very top of this pyramid, you come to refined directions like machine learning (if you can’t write your own behavior, add another layer of code that will solve this problem for you).Many will tell you that the point of programming is to write clear instructions in a language that even the dumbest computer can understand . But David Wheeler's quote offers a deeper look at the question. To be a good programmer means to climb the ladder of indirection, striving for the most common solutions.A bonus quote onIndirectness is a powerful tool, but you have to pay for complexity. People rarely cite the statement immediately following the famous quote:“This usually creates a new problem.” - David Wheeler.
It is thanks to this truth that programmers have long remained in business.2. About simplicity
“Simplicity is a Prerequisite for Reliability” - Edsger Dijkstra
There is no shortage of wise programmers who warn us against complicating code without an urgent need. But few managed to show so clearly what the complexity is for us as a pioneer in computer science, Edsger Dijkstra .This is the point: you make a choice in favor of simplicity not just out of a desire to make the future pleasing to people. And not because you assume the ability to reuse this code in the future. And not because you want it to look more accurately at the inspections, and not because you want to facilitate the process of making changes in the future (although all this, of course, is a valuable advantage). You do this because simplicity is a prerequisite. Without it, you will never have a reliable code that you can entrust with running a business or working with data.To take Dijkstra's position, we need to change our understanding of what “good code” is. This is not necessarily the most concise code, or the fastest, and certainly not the most abstruse. Good code is code you can rely on.A bonus quote on a topicOne of the best ways to keep code simple is to remember that less is more. Dijkstra offers a new unit of measurement that will always remind us of this:“If we want to count the number of lines of code, we should not perceive them as written, but as spent” - Edsger Dijkstra
3. About readability and rewriting
“Code is harder to read than to write” - Joel Spolsky
At first glance, this quote from Joel Spolsky , programming legend and co-founder of Stack Overflow, seems reasonable, but deceptively superficial. Yes, code fragments are information rich, overly compressed, or tiresomely long. And this applies not only to what other people wrote. If you look at your own work of last year, you will need some time to recreate the logic that you once knew from and to.But Spolsky’s observation unfolds in something interesting. The danger of a code that is difficult to read is not only the most obvious consequences (it is difficult to correct and improve it). There is another, big danger: code that is difficult to read seems worse than it actually is. In fact, understanding someone else's code may seem such an overwhelming task that you will be tempted to do what Spolsky calls the grossest of all mistakes - to rewrite everything again.I'm not saying that system architecture never benefits from such rewrites. Of course, it happens that wins. But an improvement of this kind is expensive. In all that concerns testing and fixing bugs - and these are two components of development that take more time than writing the code itself - you return to the starting position. Rewriting looks tempting because it fits into one of the most common misconceptions of developers - the tendency to underestimate the labor costs of conceptually simple things. That is why 50% of the time is spent on the final 5% of the project. Elementary tasks can be surprisingly time consuming! And the solution to a problem that has already been solved in the past always looks simple.Well, if you rewrite everything from scratch to bring the code to perfection, it should not, then what are the more successful alternatives? Answer: involve each developer in the process of continuous fragmented refactoring . So your code is constantly being improved, due to a chain of small changes - a real benefit with minimal risks. Readability can be improved along the way.Bonus quote to the topicIf you still doubt the importance of readability, Martin Fowler will help to look at the problem more broadly:“Any fool can write code that computers can understand. Good programmers write code that people can understand. ”- Martin Fowler
In other words, the programmer's task is to issue not just working code, but code with internal logic.4. About repetitions
“Do not repeat. Each piece of knowledge must have a unique, unambiguous, reliable representation in the system ”- Andy Hunt and David Thomas
Every self-respecting programmer knows that many troubles lie in repetition. If you write the same thing in several places, you have to spend more effort on testing and fixing bugs. Worse, you create the conditions for discrepancies; for example, one piece of code may subsequently be updated, and other related procedures may not be brought into compliance. A divergent program is a program that cannot be trusted, and a program that cannot be trusted cannot be considered a viable solution.This bug could be avoided with the method.GetTeamUniform()However, repetitions wreak havoc not only in the code. This version of the well-known DRY principle (Don’t Repeat Yourself) interprets the principle of eliminating duplicates broadly, covering other places where repetitions can make their way. Now the conversation is no longer about duplicates in the code - we are talking about repetitions throughout the system as well. And systems encode knowledge in various formats. In particular, these are:- Operators
- Code Comments
- Documentation for developers or customers
- Data schemas (e.g. database tables)
- Other specifications - test plans, process organization documents, assembly rules
All of these groups may overlap in content. And when this happens, there is a risk that they will begin to broadcast different versions of one reality. Let's say what to do if the documentation describes one model of work, and the application itself follows a different one? What in this case is considered the holder of truth? But what if the tables in the database do not match the data model from the code? Or if the code comments describe an operation or algorithm that is fundamentally different from the actual implementation? Each system needs a single, reliable representation on which everything else rests.By the way, one should not think that conflicts between applicants for truth happen only in small projects or are the result of poor quality code. One of the best examples that has flashed in plain sight is the battle between XHTML and HTML5. One side claimed that the specifications - this is the official correct version, and browsers should adapt to it. Another camp objected that it was the behavior of browsers that should be considered the de facto standard - after all, that is how designers imagined everything when they wrote web pages. Ultimately, the version of truth that browsers promoted won . Since then, HTML5 is what browsers really do, including valid shortcuts and errors.Bonus quote in the topic.The possibility that the code and the comments to it conflict with each other has generated lively discussions: what more is there from the comments — good or bad? Supporters of extreme programming treat them with outright distrust.“The code never lies, but this happens with comments” - Ron Jeffries
5. About complex problems
“In computer science, there are only two complex problems - invalidating the cache and coming up with names” - Phil Carleton
In appearance, this quote seems to be just a programmer's joke, funny, but not standing out from the others. Everyone can feel the contrast between something that sounds like a daunting task (invalidating a cache) and something that sounds like a real nonsense (inventing names). Any programmer has at least once killed whole hours for some ridiculously small problem - two parameters, put in the wrong order, a variable that is somewhere with a capital letter and somewhere not (thanks, JavaScript!). While people have to work with computers to achieve their goals, programming will always be a mixture of high-level system planning and stupid typos.But if we look more closely at the words of Phil Cardboard, we will find here more room for thought. It’s hard to come up with names, not just because of the small headaches that a programmer has, all his life goes head over heels. The point here is that names are one of the facets of the programmer’s main task, program design. In other words, how is clear, neat, and consistent code generally written?There are many varieties of bad names. We all met variables that were named after data types ( myString, obj), abbreviations ( pci.e. product catalog), some insignificant implementation details ( swappable_name, formUserInput), or even left nameless ( ret_value,tempArray) It is easy to fall into a trap and name a variable based on what you are doing with it now, and not from its contents. And with the values ​​of logical data types, the trouble is: what does it mean progress- that progress has already begun, that you need to display information about the progress in the interface, or something else in general?Source: CommitStrip.comTransfer«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
But variable names are just the beginning. When you start coming up with names for classes, the question arises of how to break the code into independent parts. The names of the public members determine what will be the presentation of the interface through which different parts of the application will interact with each other. By assigning a name to a piece of code, you are not just describing what it can do - you are setting what it will do.Bonus quote in the topic.« – , » —