10 signs php-application "with a nice"
If you order applications to third-party developers, a prerequisite is to evaluate its quality after the developer has passed the code to you. You can be a guru in software, then this article is not for you, but if you need a few simple quality assessment points, here they are:
1. The program attempts to reinvent the object model or “fix” language features.
Try searching for a class called Object. If you succeed in this, then this is a sure sign that the author is trying to invent an object model (most often this comes from the lack of understanding of it). It can be safely assumed that his “corrections” will not stop there. Our advice when meeting with such a developer: disconnect the phone and change the mailing address.
2. The code uses custom global variables.
')
A search by the code of the words “global” or “$ GLOBALS” can reveal many interesting things to you, for example:
global $ database, $ my, $ mainframe;
If you can tell me what is contained in the last two variables, you are either intimately familiar with the author of the lines of the program from which this example is taken, or psycho. The likelihood of the second option increases if you can tell what value any of these variables will take in different periods of time. In short, a sure sign that you got shit - global variables.
3. Mixed html and SQL.
If you can find the HTML code along with SQL in one of the project files, you should know that there is a crap code in front of you.
4. The class knows too much.
Find by file the largest class in the project. Look at its name. Can you uniquely define what he is doing? Look at the methods of this class. Are they connected by a common meaning? If you both answered unequivocally "no", run away with shouts from such a developer.
5. Too many public or static properties.
If you find a lot of properties declared as “public static”, multiply your conclusions about shitty by three.
6. Multiple levels of inheritance.
From more than two levels of inheritance in the PHP code, one should run as from the plague. Of course, any rule can be an exception. For example, if you have no doubt that your developers are as professional as the developers of ZendFramework. If you find the correct use of more than two levels of inheritance in lesser-known (unknown to anyone) products - you are very lucky.
7. Authors try to use design patterns.
To find out whether the authors had such a desire - look for the words “factory”, “decorator”, “strategy”. If you find something, the task becomes more complicated: now you need someone who really KNOWS how templates should be implemented. If you managed to find such a person and he said that everything is in order, and the authors did not just “try to use”, but used patterns. Then you are very lucky. Before you - not a crap.
8. Changing the error-level leads to increased talkativeness of the application.
Look for the error_level files. With luck, replace the value with E_STRICT. If the application then appeared a bunch of warning (and warning) and notice (notice), then get acquainted - shit code.
9. In the directory structure there is a folder called “core”.
It, as a rule, contains the “common” parts for the application. Despite this good intention, most often it is a sign of shit code.
10. The application uses its own template engine.
Be wary, this is really scary. These guys will reinvent the wheel again and again. Before you shit code. Ignore this warning and they will soon invent a for cycle for you.
The article is a free translation of this .
UPD. It seems the tone of the article seemed too sharp to the jury, minus the karma. I beg your petition, my dear (behind the scenes Regina Dubovitskaya's laughter).
UPD2. Perhaps it makes sense to listen to the recommendations and get away from the categorical. Too violently all react to it. Well, add "because" to each item.
1. The program attempts to reinvent the object model or “fix” language features.
Try searching for a class called Object. If you succeed in this, then this is a sure sign that the author is trying to invent an object model (most often this comes from the lack of understanding of it). It can be safely assumed that his “corrections” will not stop there. Our advice when meeting with such a developer: disconnect the phone and change the mailing address.
2. The code uses custom global variables.
')
A search by the code of the words “global” or “$ GLOBALS” can reveal many interesting things to you, for example:
global $ database, $ my, $ mainframe;
If you can tell me what is contained in the last two variables, you are either intimately familiar with the author of the lines of the program from which this example is taken, or psycho. The likelihood of the second option increases if you can tell what value any of these variables will take in different periods of time. In short, a sure sign that you got shit - global variables.
3. Mixed html and SQL.
If you can find the HTML code along with SQL in one of the project files, you should know that there is a crap code in front of you.
4. The class knows too much.
Find by file the largest class in the project. Look at its name. Can you uniquely define what he is doing? Look at the methods of this class. Are they connected by a common meaning? If you both answered unequivocally "no", run away with shouts from such a developer.
5. Too many public or static properties.
If you find a lot of properties declared as “public static”, multiply your conclusions about shitty by three.
6. Multiple levels of inheritance.
From more than two levels of inheritance in the PHP code, one should run as from the plague. Of course, any rule can be an exception. For example, if you have no doubt that your developers are as professional as the developers of ZendFramework. If you find the correct use of more than two levels of inheritance in lesser-known (unknown to anyone) products - you are very lucky.
7. Authors try to use design patterns.
To find out whether the authors had such a desire - look for the words “factory”, “decorator”, “strategy”. If you find something, the task becomes more complicated: now you need someone who really KNOWS how templates should be implemented. If you managed to find such a person and he said that everything is in order, and the authors did not just “try to use”, but used patterns. Then you are very lucky. Before you - not a crap.
8. Changing the error-level leads to increased talkativeness of the application.
Look for the error_level files. With luck, replace the value with E_STRICT. If the application then appeared a bunch of warning (and warning) and notice (notice), then get acquainted - shit code.
9. In the directory structure there is a folder called “core”.
It, as a rule, contains the “common” parts for the application. Despite this good intention, most often it is a sign of shit code.
10. The application uses its own template engine.
Be wary, this is really scary. These guys will reinvent the wheel again and again. Before you shit code. Ignore this warning and they will soon invent a for cycle for you.
The article is a free translation of this .
UPD. It seems the tone of the article seemed too sharp to the jury, minus the karma. I beg your petition, my dear (behind the scenes Regina Dubovitskaya's laughter).
UPD2. Perhaps it makes sense to listen to the recommendations and get away from the categorical. Too violently all react to it. Well, add "because" to each item.
Source: https://habr.com/ru/post/63629/
All Articles