Read the code, the compiler handles the rest.

Introduction

This is not the first time I have been asked about related questions:
“Why do you do so many functions?”;
"Why do you take out, once used, the code in the function?";
“The others are not familiar with your naming conventions. How will they work with it? ” Therefore, I will describe my vision of the problem. Well, the community will tell you what to strive for.

Situations

In the process, there is a different code. It should be accompanied, to correct errors in it, to add new functionality. A new code is also being written, with which it is necessary to work with others later. I will describe several situations:

Situation # 1 Code does too much

There is a dominant method in the class that is slightly smaller than the class itself, while it contains all the logic and infrastructure code;

Situation number 2 The logic of the code is clear only after studying it.

The code is small, but what it does is difficult to understand;
')

Situation №3 Added new functionality

There is a rather complicated code in which you need to add new functions;

Situation number 4 Writes a new code

The code should have a low connectivity, good test coverage, maintainability, etc.

The reasons

In each of these situations, I try to do minimal refactoring. I make the code more understandable and simple.

Most often, I put the code in the method. If API allows, then I do more complex refactorings. Conditional expressions, if they are not immediately clear, I try to bring to the method with a clear name.

I always follow the rule: “the code must be read, not compiled and executed,” which is fully consistent with the ideology described by Fowler.
Each function should have a good name, if it does not do what is described in the name, it should be chosen a new name. Comments that are code translation are superfluous (Exception - Error).

I always strive to keep the code less smelling than it was before. About code smells can be read by many, in particular, by Fowler.

Effects

Almost after each more or less substantial editing, I am asked the questions described above. They say that the code has become less clear, it becomes difficult to find the desired string, etc.

The reasons

In fact, the problem lies in both the code and the developer, who is used to the code.

I propose to conduct an experiment.

Take an unknown piece of code that is well written. It must have methods with complexity less than 5 (meaning a simplified interpretation of the cyclomatic evaluation ). If you find it hard to read this code, then note that you are trying to translate the code. Check how the program will be executed, so the inconvenience is caused by a constant jump from method to method. You compile and run the code in your head.

If the code is easy to read, then most likely you pay more attention to the method signatures, their names. You are reading the code.

For code containing several functions with complexity more than 30, the opposite is true (for example, more than 100 lines). It is impossible to read, but execution can bear fruit. If you don’t get lost in the fifteenth condition clause at the twentieth iteration of the loop ... Good luck!

Conclusion

It can be said that the simpler the code, the better. Only if it seems to you that your code is simple, can it be simplified by a few more points. It's okay that the function is now used in one place, nothing that its name is more than 20 characters. The main thing that the code was read, it can be said, as an art book. It is the code, not the comments.

Good examples can be found in the writings of Glass, Fowler, McConnell, Martin.

Another good quality control of the code are the tests. Not in the sense that there are no errors in it - errors are everywhere. If, while writing a test, you thought about how to test the code for a couple of minutes, then it is actually complicated, it can be simplified. At times, real insights come.

Write and read your code, and the compiler will do the rest!

Useful links:
1. Perfect code. S. McConnell
2. Refactoring. Improve existing code. M. Fowler
3. Clean code. R. Martin
4. Greg Wilson - It's True
5. SOLID Principles with Uncle Bob - Robert C. Martin
6. A good English resource sourcemaking.com