Code, Don’t Do Stunts

The advanced principles of clean code will actually help you to become an easily understood developer who is able to code more cleanly. They teach you to be consistent in your choices, to think about other developers and your team, and to make communication the main tool of our work. Even before the source code.

It’s a fact: although the source code has a preponderant place in the developer’s job, we should not make it our main reason to be. It is a reality: the developer’s job is not to write code. It’s about finding a solution to a given problem while adapting to constraints that would get in the way. This is the basis of our job that we must absolutely keep in mind. And although the principles we have just seen in the previous chapter, such as SOLID, seem to be strongly linked to the code, we must try to have a more “meta” perspective on all this, thinking outside the box, and taking a step back. The principles...

Understanding code

Let’s first ask ourselves about the importance of code. What really is its importance for us developers in our daily lives? For that, let’s go back in time.

A bit of history

Computer programming is, in fact, a transistor through which an electric current passes or does not pass. So, we end up with a binary system, with a value of 0 if the electric current does not pass through the transistor, and 1 if the electric current does pass. If you multiply this number of transistors by several billion, you end up with today’s processors. It works very well, and our world has been governed by this system for decades. However, there is a clear limitation: it is not humanly possible to understand and create applications with only 0s and 1s. So, we had to find a new way of writing these programs so that they became humanly possible and manageable.

We then move to the first human-readable source code: the assembly language (often abbreviated ASM...

Be understood, not clever

It happens very often that in front of technical challenges and especially in source code, we want to do things in a fine, pretty, even “sexy” way, as some would say. This is completely normal—since code is a major part of our lives as developers, we sometimes want to show the extent of our abilities. Although this can be justified at times, it is often an awfully bad idea to want to show the complete extent of these talents. Obviously, our ego takes a hit—we must hold back sometimes. You just learned new ways of doing things, new ways of coding, and new principles of which you are ardently convinced. You have spent a weekend learning this new way of organizing your code and your project, you experience it as a revelation, and you are sure of it: you must show this new discovery to your colleagues and your team; it will revolutionize the project and bring only good things. Moreover, you will be given the credit for this new thing...

A note on maintainability

And this is where it gets complicated. Your code is ready—it works. You have followed a new programming method, and the preliminary developments of the project have been going smoothly for several months. And it’s pretty obvious: there may have been no foundation on which to build your project; you were lucky enough to start from a blank sheet of paper. However, the question of maintainability will soon arise. Whichever programming technique you choose, whichever people are working on it, bugs will always appear. You may need new people to fix all this (and thus teach them your working methods). Are you sure that you have mastered your new methodologies enough to ensure the follow-up of an application over several years? It is quite possible, but you must be aware of this and know what to do if you get stuck on the maintenance of your application.

The purpose of this chapter is not to discourage initiative and the testing of new work methodologies...

Summary

Do you understand what is meant by “building on what we know”? We realize with a little hindsight that this is again a lot of common sense and altruism, thinking of the next developers who will pass over our code. Here, there was no question of scouts, SOLID, Keep It Simple, Stupid (KISS), or other principles. It’s about rethinking our very methods of writing code.

We must remember that the basics can (and should) be questioned and not considered as set in stone. Self-confidence is a wonderful thing, and if you are able to combine this with continuous questioning of your habits in a perspective of continuous improvement, you are on the right track to becoming an excellent developer, being able to write clean code naturally, and bringing your collaborators with you in this practice.

Taking the initiative is a remarkable thing; knowing the risks and evaluating them in your context is the key to striving for perfection. This way, you are able to know...