There is no formal definition and I doubt that one day will exist (it is symptomatic that there is no entry in Wikipedia). He is subjective. Whenever someone says what it is, be wary. But of course some observations can be made regardless of opinion. It is obvious that they are vague and will not help much to define clearly what the term is, but they will not make biased assumptions either.
- The flow of application execution is easily understandable, no matter what paradigm, (do not understand flow only as the imperative flow).
- The various objects (nothing to do with OOP) have clearly defined relationships and are easy to see.
- The role and responsibility of each application participant (classes, functions, variables, etc.) are clear, possibly with well chosen name.
At the moment I can not remember anything else that is not specific and too subjective to be applied as a general way of understanding the subject.
So the code needs:
- Be easy to understand by anyone who has not seen it before.
- Enables maintenance with no major jolts.
- It works correctly .
Of course, the code reader is expected to be a skilled developer, one who understands the language in which it is written and understands the fundamentals of computing. Unless a code is written for didactic purposes it is not an obligation of the clean code to explain in any way its functioning to lay people (even those who are paid as developers, this exists, and much).
Here we can start defining some more specific things that help meet these three requirements highlighted above:
- Code units should be short and have only one responsibility.
- The "public" parts (the API) should be clear (obvious, no surprises) and concise (make the minimum necessary).
- Data structures and algorithms should work as expected.
- The code should be easily verifiable.
- Codes should be organized and expressive (concisely indicates their intention)
Furthermore it is probably going beyond the basic definition and begins to enter the subjective field.
I even used a very recent source to write this response. Nor will I quote it because my text is sufficiently different and the original induces the dictatorship of the mono paradigm that so well the PA reneged. Paradigms are not magic, they do not solve problems. They are tools that can be more or less suitable.
The first chapter of the book is available as an article . As the book goes deeper he goes on to suggest certain things that are debatable. The book is not bad, everyone should read it, but those who are not sufficiently prepared end up indiscriminately buying some dubious techniques.
In the question that was quoted by the AP I do a quick review of the book and another that deals with similar subject .
Just an addendum to not go over the false impression that 100% of the written code should be cleaned. Of course this would be ideal but there are certain domains in conjunction with certain requirements that conflicts with the concept of clean code. It may be rare, not to be applicable to certain types of projects, but there are situations like this. As in everything, you should know when to pursue an ideal and when to be pragmatic and solve the problem in the most appropriate way.
