2

Who Gets to Decide What “Good Practices” Are?

Good practices are great but knowing who decides them and where they come from is better. It is no secret that when you fully understand what you are doing, you immediately feel better and more comfortable. The same thing applies to good practices. Why should you believe without question these precepts decided by people you do not know and who have never collaborated with you on your project?

You could say that the people dictating these principles have more experience than you and know this world better than you do. Two things. First, maybe one day you will have more experience than they do. Maybe you will be better. Maybe you already are. Second, years of experience are not everything. It is common to see developers with 20 or 30 years of experience who are completely out of date or with habits from the last century. Years of experience can be an argument, but not the only one. Computing evolves at an exceptional speed, and the web world is even more affected by this.

We’re going to see together in this chapter where best practices have originated from: were they really invented and decided by a precise group of people? What are the different existing clean-code principles that you can already apply to your projects starting from now? Your way of thinking might change once you know them.

Here are the main topics we’ll cover in this chapter:

• Who decides these things anyway?
• Best practices—where do they really come from?
• Being context-aware
• Being consistent—get results quicker

Who decides these things anyway?

One thing we are going to see is that you should always question “good practices” and never consider them as a general truth that you must respect without understanding why. One excellent way to improve yourself is to ask every time you do not agree with someone’s review or point of view. Developers are fascinating as they can find unlimited ways to solve a single problem—unlimited solutions for the same result. Even if this can be seen as something a bit tiring sometimes, it is always interesting to understand why a developer wants to solve a problem in a different way than you. There are multiple goals to this, as follows:

• You will improve your communication skills: If you want to communicate and be understood, you will have to explain your problem clearly.
• You may learn new ways of doing things: We are all using the same language, but we all have different experiences with it. These different career and life paths can bring terrific ideas to the table.
• You are reinforcing your relationship with this developer, which will make it easier to discuss further subjects in the future.
• You are improving your teamwork skills and all the participants in the conversation are improving their skills, respectively.

That is a pretty long list. A lot of soft skills are improved just by discussing with other developers a way to solve a given problem. Being able to explain a situation clearly is way harder than it seems.

And this is also why you should always ask for further explanation when you disagree with someone. First, there can be a misunderstanding about the exposed problem. This is a common situation where multiple parties are disagreeing: the problem was not clear at first. Each party is trying to justify what they understood. You can easily imagine the mess it brings.

Being a good developer is (also) being able to justify and explain all your choices. No more: “We always made things like this; there are no other reasons to do it this way.” When you are deciding or telling someone to follow some guidelines, you must always be able to justify and explain clearly why your way is the best for you. It may not be the best way to do it objectively, but if you are able to explain why it is best suited to you, it will make you look way more open-minded.

That being said, you may now understand where we are going with this: no one holds the absolute truth. If someone is confident enough to say so, you should always be careful.

Best practices – where do they really come from?

When we are talking about “best practices," we can differentiate three cases, as follows:

• Principles that have been proven for decades to work, which also are deduced from common sense: In this category, we can—for example—find design patterns. In short and if you do not know them, these are tools that fix recurrent programming problems. They have been here for decades and are known by millions of developers.
• Choices made because we had to make them: Here, we can find things such as code style, naming conventions, and so on. Technically, it does not matter if you would like to use camelCase or snake_case to name your files. But if everyone is following the same rule, it is easier for everybody to understand each other.
• “Technical” best practices: Some “best practices” are actually dictated by technical constraints and features. A concrete example is “method name guessing” in PHP: Hypertext Preprocessor (PHP). Let’s say you would like to guess “getters” (accessors) and “setters” (mutators) of an attribute of a PHP class. You are likely to try methods starting with get, set, is, and so on. If everyone has their own rules about naming accessors and mutators, you can be sure that someday and without warning, things will blow out.

Design pattern principles

The design patterns case describes objective solutions to solve problems. You can dislike them and how the code is being organized by them but cannot say that they are objectively bad. Because your thoughts on them do not matter, they work.

Talking about principles that have been present for decades, we can highlight four famous ones: DRY, KISS, YAGNI, and SOLID.

DRY

DRY stands for Don’t Repeat Yourself. This principle simply states that you should never have, in your application, two authorities doing the very same thing. It may sound obvious, but applying this may not always be a reflex, especially when you are new to application programming. Having the same responsibility at two separate places in your code means maintaining those two places every time you fix something. It means having to think about these two places at each change (and someday, you are going to forget one, for sure). Also, how is any developer maintaining your source code supposed to know which one to use if two things have the same responsibility?

KISS

KISS stands for Keep It Simple, Stupid. Sometimes, we complicate our lives. We can see two main reasons for this, as follows:

• First, we try to do complicated things with our code, but these stunts do not bring anything valuable and complicate the code. We will see later in this book in detail why we absolutely need to avoid this.
• The second reason is a lack of perspective on what we are doing. We have spent many hours trying to solve something, and we are too much “into it." Some rest is necessary to get this perspective and, sometimes, start it all over again.

Both cases are recurrent and prevent us from going straight to the point and keeping things simple. When you feel you are going “too far," think of this acronym to get back on the rails.

YAGNI

YAGNI stands for You Aren’t Gonna Need It. In some way, it goes hand in hand with the KISS principle. It is quite common (not to say part of our daily lives as developers) to want to find a solution to a problem by thinking about the future. Indeed, we regularly have this thought: “If tomorrow I need to do such and such a thing, at least this will already be in place.” The reality is that, in general, no—we will never have the need that we want to try to foresee. Then, by trying to get ahead of a task that may never exist and whose functional constraints are unknown, not only do we waste time, but we also complicate our lives by thinking too far ahead. We move away from our initial goal, which is to find a quick, viable, and robust solution.

We are not psychic, and we cannot know all the problems that will appear if the task we predicted appears. You will quickly realize that if you keep things simple and without superfluous additions to try to get ahead of the game for the next day, you will have a healthy, no-frills code base. This means a faster understanding of the code, greater ease in navigating through it, and making changes when they are really needed. Plus, you will probably save yourself a lot of bugs. It is always complicated (if not impossible) to justify that a bug was made in your source code because you developed and spent time on something that was not asked of you. If your job as a developer requires you to collaborate directly with the customer, you should know that the customer will not pay you for something they did not ask for. You will have worked for free, which is never ideal.

Caution: It is obviously necessary to take this on a per-case basis. We can take as an example magic numbers. Magic numbers are constant values, mainly numbers, hardcoded and without any explanation of their meaning.

Verdict: Two weeks later, everyone has forgotten what this number corresponds to. We will then think of using well-named code constants. However, there is a huge chance that the value of this code constant will never change because the needs would have changed. At first sight, it would be strange to want to declare a constant to use it everywhere. The purpose of code constants is to add semantics to fixed values and allow us to easily change that value everywhere it is used in the code, at once. This is, in a sense, contrary to YAGNI (since these values will probably never change).

However, we can see the value of using constants. Perspective and reflection are always necessary, whatever the clean-code principles applied.

SOLID

Finally, maybe the most famous one, SOLID. Let’s see what these letters stand for:

• S stands for single-responsibility principle (often abbreviated to SRP). Very simply, it means that a class in your code must respond to only one task. Obviously, the size of that task is the key point here. We are not talking about creating a class with only one available method. Rather, we are talking about creating a logical breakdown. A very concrete example is the model-view-controller (MVC) architecture. The important thing to remember is that you must avoid having catch-all classes, grouping together database operations, Hypertext Markup Language (HTML) rendering, business logic, and so on. The breakdown must be logical. An example of a breakdown could be a class for generating HTML, a class for database interactions for a given object, and so on.
• O stands for open/closed principle (OCP). You will often find the following definition for this principle: a class must be open to extension and closed to modification. Concretely, in the code, this is materialized by the strong use of polymorphism and the use of interfaces rather than by conditional branching with multiple if and else statements. Indeed, if you use conditional branching, you incur a modification of the class, and this can quickly become unmanageable if you have more than two cases. By extending a class and overloading the methods you are interested in, you get concise code, well broken up and without branching of several hundred lines.
• L stands for Liskov substitution principle (LSP). Behind this complicated name is actually something quite trivial. In fact, this principle simply says that when you use an interface implementation, you should be able to replace it with another implementation without having to modify the implementation in any way. In the code, this translates into the fact that the implementations of an interface must be similar, especially regarding the return values of the methods (if one implementation returns a string when calling the foo method and another implementation returns an object, it will be complicated). Fortunately, the typing of return values exists in recent versions of PHP, limiting the possibilities of violation of this principle.
• I stands for interface segregation principle (ISP). This describes that a class implementing an interface should not be forced to implement or depend on other methods of the interface that it does not use. Concretely, this principle will prevent you from creating an interface with dozens of methods in it that are there just in case. It is better to create several interfaces (joining the principle of single responsibility), even little ones, with a very precise goal and responsibility. Then, you’ll be able to implement them unitarily in your class.PHP allows a class to implement as many interfaces as we want, so this works perfectly fine. Thanks to this, the implementation we describe will only know the methods that are useful to it. Otherwise, we would end up with dozens of methods with an empty body or returning a null value. When you put it like that, you realize that it does not sound like very "clean code."
• Finally, D stands for dependency inversion principle (DIP). Once again, this is a term that may seem complex at first glance but hides a much simpler reality. Very concretely and in the code, it materializes by using interfaces and abstraction rather than implementations. For example, when you type the argument of a method, you use the interface as the type. This will allow you to make full use of polymorphism and to take full advantage of Liskov substitution. By using the interface as a type, you will be able to send as an argument to the function any implementation of the interface. To give an example, if you need to send emails in an application, chances are you will create a MailerInterface interface. You will then have one implementation per mail service. By typing the argument with the interface, the method will be able to receive any implementation and use the right email service for your case.

We can quickly realize that these principles are very much linked. They work together, and they allow a strong decoupling, a strong separation of responsibilities, and a fluid thinking when you have these principles in mind while writing code. It can be extremely helpful to remember these principles; at least, it is a particularly good thing to know their existence. Apart from the SOLID principle, you can see that KISS, DRY, and YAGNI are pretty common-sense and logical. Remembering them from time to time can be beneficial and can help us to put up barriers when we get a little off track.

Bonus – Scouts’ principle

Something that can also be added, which is also a common-sense principle, is the “Scouts’ principle." We all know those groups of young people and teenagers that act with a benevolent purpose and show a great deal of altruism. The Scouts go camping in the woods, build a fire, and spend the night there. Once they get up in the morning, they might put out the fire and put away their stuff, but most of all, they clean up the place to make it cleaner than it was before they arrived (at least, in theory).

As a developer, it is the same. Be a Scout. When exploring and browsing the code, if time and context allow, it is often a particularly clever idea to clean up where you see some technical debt. If you are going through places in the code base and think “this is really bad," maybe this is an opportunity to make it more manageable and cleaner. If everyone gets on board, the quality of the project’s source code can rise very quickly.

Of course, this “Scouts’ principle” must be done in accordance with your project constraints, time constraints, and customer needs. Moreover, it is quite risky, and you must know when to stop. When you send your changes to your team for review, the changes and cleanup you have done must be consistent. You do not want to rewrite half the application every time you find a little thing, which leads to another, then another, and so on. It’s more about cleaning up the things that are relevant to what you’re doing. It can be extremely complicated to stay focused and fixed on your context. There is no genuine answer to “when to stop”; it will depend a lot on the time you have and your task. However, there is nothing to stop you from writing down things that you want to come back to but that unfortunately were not related to what you were doing, that seemed too energy- and time-consuming, or that simply require further reflection with the team.

On the opposite side, code style, naming conventions, and similar things are subject to tastes and habits. Everyone has their own tastes and habits, so decisions need to be made. As we discussed earlier, it is so much easier to talk together when we all follow the same rules.

So, who decides these best practices in a team or an organization? Well, generally, it is a consensus after lengthy discussions about the subject at the beginning of a project. Because yes—“best practices” are not something that you can always apply everywhere, and you should be aware of this. You should be aware of the context you are in.

Being context-aware

Here, we enter one of the most important parts when we talk about clean code. If there were only one thing to remember, it would be this. We may regularly talk about the rules defined by other developers, object principles, and the principles of clean code, but nothing will ever be as good as what we are going to talk about here: it is about being aware of your context. One thing that is missing from many books and articles about clean code is the feeling that it is relevant to everyday life. A developer’s life is made up of unexpected events, technical constraints, impossibilities to do some things, or being forced to do some other things.

There are as many ways of doing things as there are projects. Each project has its own history, technical decisions, and constraints. As a result, we end up with many theoretical principles that are not applicable or that would break the coherence of the project. Good practices may dictate how you name variables, how you name your classes and methods, how you name your files, or how you make up the tree structure of your project. However, what if this goes against what has been set up in the project? This is a problem that arises very regularly, especially on so-called “legacy” projects.

The answer is both simple and complicated. It is simple because it can be summed up in one sentence: discuss it with your team and the other people working on the project. This is where the answer can become complicated because it will most likely start debates (sometimes heated) within the team, and this is quite normal. But the important thing is this: you must not only find a common ground that everyone will respect to be consistent with the project, but also find ways that work best for you and your team.

This may be the cornerstone of all these discussions: you may have good practices and clean-code principles, but maybe some rules are worth bending because it just works better for you and your team. This is a perfectly valid reason to deviate from certain principles (not all of them, of course, otherwise it is total anarchy). Sometimes, no common ground will be found, and that’s when best practices and other principles can prevail in dictating a rule that everyone will have to follow, if not one that works for everyone.

And that is when we come back to a point made earlier. Having common rules in a team of developers helps to make it easier to be understood. Navigating through the project is easier, as is navigating through files. By all speaking the same language, we understand each other better. Whether it is helping someone or being helped, it is always the same story. If common naming and indentation rules are respected, not only do you avoid sterile debates that would distract you from your initial goal, but if you feel that the code written by your teammate is written by you, it is a win-win.

We can summarize the choice of deciding on good practice and “classic” principles of clean code in this way:

Has your situation already occurred in the past in the project?

• Yes. Does it respect the principles of clean code and the good practices dictated by the tools you use (such as Symfony’s good practices)?
  • Yes. In this case, you just have to follow the way the situation has been handled in the past.
  • No. You should talk to your team to find out why. There may be historical reasons due to functional and/or technical constraints, or maybe there is no reason at all. In this case, if you agree, you can follow the good practices (and even update the other parts of the code concerned if you have the possibility, and the time, to respect the “Scouts’ principle” we discussed earlier, in the previous section).
• No. Is it possible to apply good practices and clean-code principles?
  • Yes. Perfect! All you have to do is apply them to the best of your ability, in accordance with the other practices in place within the team and the project.
  • No. In this case, you should discuss it with your team, but perhaps also discuss it with people outside the project who have had this case. Again, these discussions can take quite a long time, and an answer will not always be found immediately. Debates will be raised, for the better. Once you have found a consensus or discussed it at length, you can either rethink the application of clean-code principles and good practices or apply rules that have been set up with the team for this kind of situation.

Here, we see very clearly, once again, that the key to success will be communication and debate. Everyone has their own point of view and approach to the problem, so it is never all black and white. But keep one thing in mind: you should avoid making decisions alone about a practice that could be debated. Avoiding making a decision alone does not mean you should not make one. Rather, what we mean by this is to think through the options, weighing up the pros and cons of each. And again, be able to justify each proposal you offer to the other people working on the project. You can be sure that you will be highly appreciated by your team if you offer several solutions to the problems with a good justification of why these solutions are appropriate, but also the risks that these solutions entail. You will quickly realize that this work can be complicated to do alone, hence the importance of discussing it with your team. Each brain has its own way of working.

By the way, all this does not only apply to IT, clean code, and PHP. That is why it was mentioned in the previous chapter that clean code is not just a set of rules: it is a way of being—it is a mindset.

Being consistent – get results quicker

Being perfectly consistent in what you do will force you to understand what you are doing. Then, everything will become a habit. If you have these good habits to the point that they have become natural to you, results will come faster in two specific cases, as outlined here:

• As we have seen from the beginning, you will be able to understand each other much faster within your team—developers will have the same habits. More rarely, but it can happen: you will sometimes have to discuss code or show things to non-technical people in your project. Although these people—such as a product owner, for example—may have some basic technical knowledge, it is best to assume that you will need to go back to the most basic basics. You will have a much easier time explaining a complex and technical subject to someone non-technical if you have done things simply, cleanly, and without hesitation in your work.
• The second case is during automated checks. Automated checks are tasks that have been set up and discussed with the team and that are executed every time you want to propose changes. These checks can take place in several places. It can be in your software to write code (IDEs such as NetBeans, PhpStorm, or Visual Studio Code (VS Code)), through continuous integration (CI) tools (GitHub Actions, GitLab CI/CD), and so on.

Automated auditing tasks can include absolutely any task you want. We will go into more detail on how to perform these tasks as soon as Chapter 7, Code Quality Tools, of this book (in the Code quality tools section), but here are the most common ones:

• Check code style and indentation
• Run test suites (unit, functional…)
• Run a static analysis of your code to make sure that the variables you use are well defined, that they use the right types, and so on
• Set up alerts to notify you of the success or failure of tasks through a chosen channel (email, instant messaging such as Slack, and so on)
• Deploy to a test environment
• Install dependencies and vendors
• Copy files to the server and do some remote operations
• Whatever you want!

You get it. These tools allow you to perform the tasks you want and need. In reality, they are just orchestrators that will play the commands you define. It is as simple as that. After that, if your commands are complex, it is another story. But you realize how infinite these automated checks can be.

About source code analysis tools

By having good code habits, you will definitely speed up the process. Perhaps the most telling and concrete example of this is style-code checking. If you do not know how to write code in your team and your team has put automatic checks on it for everything you want to change, you may spend hours figuring out that a space was missing in one place, a line break in another, and so on. Do not worry—most tools offer options to correct these errors automatically.

However, this is not the case with static analysis tools, such as the ones we’re going to set up in the section dedicated to static analysis tools in Chapter 7, Code Quality Tools. In fact, a static analysis will review your code and make sure that the most common errors are not made. We are not talking about checking the number of spaces in your tabs, but really parsing the PHP to try to understand it and make sure everything is in order. These tools can be a bit too strict at times, and it can take a lot of time to understand them properly. Also, these tools are not perfect, and the static analysis tool may not be able to understand what you want to do. Although this is a separate issue, you will save yourself a lot of trouble if you deal with it at the source: develop good coding habits. Be thorough and do not leave anything to chance. PHP is a very lax language that allows you to do just about anything with variables—for example, allowing you to typecast without flinching. As we know, the results of this kind of operation can be random, even very surprising, and may seem completely illogical. Anyway, PHP is what it is. Although static analysis tools can spot these risky cases most of the time, you may spend hours correcting these small things that can number in the dozens very quickly.

Also (and this may sound silly), the cleaner you code by implementing clean code practices and what follows, the fewer bugs you implement. By being sure of yourself, you save yourself a lot of scares. Moreover, you allow the next developers who will pass over your code not to be fooled too and make their passage easier. If you are lucky enough (or if you have applied the principles of clean code and what goes around it!), you will have tests that ensure the proper functioning of the application. Maybe you are not familiar with tests, so let’s go through this together.

About testing and its multiple forms

Tests are mostly lines of code written by the developers. These tests make sure that for some input data, a specific output is returned. These inputs and outputs (I/Os) can be of diverse types and sizes. It can be an integer as well as a generated HTML page or even an image. To make things easier and to simplify the concept, automated tests are generally grouped into three main families, as follows:

• Unit tests, which are the tests with the finest granularity. They generally assess the return of the methods in the code while ignoring everything that surrounds them. What matters is the result returned by the function, and that’s all.
• Functional tests have a medium granularity. They will assess full-fledged functionalities, where several parties and methods can be involved. The most obvious example is the testing of an application programming interface (API): we check that if we call a specific Uniform Resource Locator (URL) with specific parameters in the request, the API returns the expected result.
• End-to-end (E2E) tests are the most complex to maintain. These tests will mostly simulate a web browser, controlled automatically. A classic example is the test of a login form. A robot will automatically fill in the fields, click on the button, make sure that we are redirected and that a success message is present on the HTML page, and so on.

All these tests exist for a specific reason: non-regression.

Non-regression testing is without a doubt the thing that will save your position as a developer in a company. Alright—maybe that is a bit of an exaggeration. However, we cannot count the number of applications that have been saved thanks to it. When your test coverage is good enough (the proportion of lines of code and features covered by one or more tests), you can modify almost anything and be sure to never break anything if the tests are always green. Indeed, you can break features to rewrite them differently and test new ways of doing things. As long as the tests are green, you can be sure that the application behaves correctly, as it did before your modifications. Of course, several things come into play.

First, the tests have to test something. This may sound strange, but in fact, you end up with a lot of tests that do not actually assess anything. The most typical example is the unit tests on the setters and getters of a class. When you write tests for that, you are assessing that a variable assignment has been done and that a method call has been done. You are testing... PHP! And PHP already has its own tests. Writing relevant tests is a book in itself and is an art that can be mastered and refined over the years. And for that, there is nothing like practice—again and again.

The second thing to consider when you modify an application is simply that the tests you have set up are no longer up to date and must be modified. Sometimes, it can be difficult to understand whether a test fails voluntarily (that is, it becomes incompatible with your changes) or involuntarily (because the application does not behave the same way as before when it should). It depends entirely on your case. Remember one thing: if your application is tested correctly, you can change any line of code and deploy your application with your eyes closed, at any time, and without hesitation. Pretty interesting, isn’t it?

Now that you see the benefit of tests in your application, we can discuss a practice that is quite common in the practice of clean code. You may have already heard of it: TDD.

TDD stands for test-driven development. It is a methodology that consists of writing tests before writing the rest of the code. At first, it is very confusing. It is complicated to understand how it happens, or even how it is possible. It is about thinking backward and questioning our thinking habits, yet the principle is quite trivial. First, we think about the tests—that is, the data we are going to send (to our methods in unit tests, to an API endpoint in the case of functional tests, and so on), as well as the output we want (a precise object or value in unit tests; a precise JavaScript Object Notation (JSON) return, for example, in the case of an API functional test). Obviously, and because you have not written the rest of the code yet, all tests fail. This is intentional. The goal is now to make these tests go green one by one.

If you try this practice, you will realize that a kind of magic happens without even realizing it. You will organize your code in a way that you would never have done at first. It will be cut up in a clear and precise way so that your tests can pass as quickly and easily as possible. In addition to the exceptional intellectual satisfaction that will result, you will end up with instantly more readable and cleaner code. Also (and contrary to widespread belief and intuition), developments will be much faster. There is indeed a period of adaptation for it to become quite natural, and you may have the impression of being awfully slow at first. However, thanks to this, your code is simpler and therefore faster to write, understand, adapt, and extend. You have to try it to experience this, as it may sound a bit miraculous. And it really is in some way.

Moreover, the code coverage becomes increasingly extensive as you develop. This has a direct impact on the maintenance of your application, as we said before: you will be much more confident in amending your code, as well as all the people who will have to read and modify it. The tests will be there to protect you. As a bonus, reading tests can be invaluable in getting into complex code. By reading the tests, you can understand from the I/Os given where the developer writing the tests was going. This is priceless in the vast majority of applications, especially legacy ones. Also, a lot of developers are looking at tests in the first place when reviewing your code. It is an amazing entry point when getting into someone’s change to the code base. See your tests as the one and only way to prove that what you just did actually works. This is a reality: most developers sensitive to clean code and alike consider tests as the only valuable proof that your changes work. 

It can be noted, for example, that for most (if not all) open source projects such as PHP, you must add tests when you make changes. Whether it’s for adding a new feature or fixing a problem, testing will be mandatory, and your changes will never be approved without testing. These tests will be, once again, irrefutable proof of the behavior of your new feature or that you have indeed fixed the bug in question. All this is a lot of work, but with this in place, the code coverage becomes huge, and you contribute fully to the stability of the software.

Testing is invaluable, both for the quality of your code and for the speed with which you get results. Thanks to it, you will be consistent, and you will get results quicker.

Summary

We have just seen a lot of new knowledge together. If you understand it, you can be sure that you are already a better developer than you were in the previous chapter.

Knowing the SOLID principles is a real asset in the professional world and in industrial-quality projects. Even if each case is different and each project has its specificities, these principles have the advantage of being applicable almost everywhere, and at least of being very strongly inspired by them.

Keeping in mind the KISS, DRY, and YAGNI principles will allow you to keep your feet on the ground and not spread yourself too thin during your next developments. They emphasize thinking about the present moment to help prepare for the future, rather than thinking about the future to try to adapt to the present moment. You should definitely remember this. We don’t know the future constraints that will be imposed on us, whether technical or functional, so it makes more sense to think about how to make it easier to deal with those constraints rather than guess at them. Because let’s face it: we have very little chance of hitting the bull’s eye.

If you have the opportunity and the possibility, implementing the “Scouts’ principle” in a TDD strategy can be more than beneficial and will always be an excellent idea. If you have never practiced TDD, and despite the explanations given in this chapter, it is quite normal to be completely dubious about its usefulness and—especially—its effectiveness. This is normal, and we have all been there. However, the results are there, and the various case studies that have been conducted on this subject demonstrate this drastically. It might be time to test this way of doing things, which is very well seen and appreciated by the seniors of clean code!

In spite of all this, we must keep in mind that clean code is also about adapting to its environment. It is not a question of rewriting the application entirely and changing all the habits of the development team under the pretext that someone outside the project has decided to do so. You must be aware of your context and deal with your environment. You must be able to adapt to the need and to what is around you. This is what will make you a good “clean-coder." Remember to communicate as much as possible with your team when a change of habit is perceived, and be able to justify all your choices. If possible, it will always be good to propose several solutions, as well as the advantages and disadvantages of each.

After all this theory, we can move on to a slightly more practical part. What are the ways to write clean code? What is the purpose of code? Although we have seen some advanced principles, we should not forget the basics, and we should also question what we already know.