Hi, guys! What is your position regarding the evaluation of the program code in your team? Do you support a regular code review or are you limited to the fact that it works as expected? Summarizing best practices in software development, you will notice that all of them pay a great attention to the code cleanliness. But how to understand whether the program got is good enough? In this article we tried to distinguish several the most important, in our opinion, criteria, which help us to estimate our own code.

In routine everyday development process it becomes a great challenge to determine how good the code, which is currently being written, is. And this is not because the developer is not smart enough for this code. The simple fact is that the created code for the developer is, by definition, already the best one, otherwise he wouldn't come up with it. Usually the rhetoric of adding crutches to the code base operates with concepts "there may be some not very beautiful parts of the code, but you just can not write here in another way", and the consequences of such arguments we all know well. There is a technique for self-checking written code, in which it is still impossible to detect all the shortcomings in your pull requests, nevertheless, most of them can be caught. This is a set of litmus papers (triggers, if you will), which you should always remember while writing the code. Here are some of them:

• Is it easy enough to test the resulting code? If there are problems with writing tests, then something here smells like a bad code.

• Can this code be scaled vertically well? And we are not about running several applications side by side, but about adding entities to the level above. Like 'company_id' if you want.

• Is it simple to come up with a name for a certain method or a variable? If the naming is not very obvious or it is thought up hard, then most likely its content is not quite evident too.

• How many methods do you need to redefine? Are there many boundary conditions being processed? Or, in the general case: how are the rules, which your functionality is based on, formulated and how many exceptions to these rules do you have? It concerns not so much business logic, as a properly chosen architecture and code structure. If there is a bug found in the system and you can fix it, only by adding one more conditional branch, then this bug did not appear from scratch, but from the incorrectly organized code structure.

There are a lot of such criteria, some of them even can not be formulated just like these, and in each particular project the requirements may vary. Moreover, a good developer already has a set of such criteria somewhere in his subconscious and defines a badly smelling piece of code precisely by them. Try to formulate these criteria for yourself in writing and constantly improve this list. In addition to the clear formulation of the shitcode, you will also get a great self-test tool, because after six months of writing your code seems not so good, and the reason of that can be seen by the new criteria that have appeared.

Riter development team