July 5, 2009 at 20:5510 signs php-application "with a darling"
If you order applications to third-party developers, a prerequisite is to evaluate its quality after the developer passed the code to you. You can be a software guru, then this article is not for you, but if you need some simple points, quality assessments, then these are:
1. The program tries to reinvent the object model or “fix” language features.
Try searching for a class called Object. If you succeeded, then this is a sure sign that the author is trying to invent an object model (most often this comes from a lack of understanding). We can safely assume that his “corrections” will not stop there. Our advice when meeting with such a developer: turn off the phone and change the mailing address.
2. The code uses custom global variables.
A search by the word code “global” or “$ GLOBALS” can reveal a lot of interesting things, for example this:
global $ database, $ my, $ mainframe;
If you can tell me what is contained in the last two variables, you are either closely acquainted with the author of the lines of the program, where this example is taken from, or crazy. The probability of the second option increases if you can say what value any of these variables will take in different periods of time. In short, a sure sign that shit code came to you - global variables.
3. Mixed html and SQL.
If you can find HTML code with SQL in one of the project files, you should know that this is shitty code.
4. The class knows too much.
Find the largest class in the project by file size. Look at its name. Can you unambiguously determine by him what he is doing? Look at the methods of this class. Are they related by a common sense? If you clearly answered “no” to both questions, run away with screams from such a developer.
5. Too many public or static properties.
If you find many properties declared as “public static”, multiply your crap conclusions by three.
6. Several levels of inheritance.
You should escape from more than two levels of inheritance in PHP code, like from a plague. Of course, there can be an exception to any rule. For example, if you have no doubt that your developers are as professional as the developers of ZendFramework. If you find the proper use of more than two levels of inheritance in lesser-known (unknown to anyone) products - you are very lucky.
7. The authors try to use design patterns.
To find out if the authors had such a desire - look for the words "factory", "decorator", "strategy". If you find something, the task is 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. You are very lucky. Before you - not shit code.
8. Changing the error-level leads to increased talkativeness of the application.
Search the error_level files. If successful, replace the value with E_STRICT. If after that a bunch of warnings and notifications (notice) appeared in the application, then get acquainted - crap.
9. In the directory structure there is a folder called "core".
It, as a rule, contains “common” parts for the application. Despite such a good intention, most often it is a sign of crap.
10. The application uses its own template engine.
Beware, this is really scary. These are the guys who will invent the wheel again and again. Here is the shitty code. Ignore this warning and they will soon invent a for loop for you.
The article is a free translation of this .
UPD It seems that the tone of the article seemed too harsh to jurors, minus karma. I apologize, my dears (behind the scenes laughter of Regina Dubovitskaya).
UPD2. Perhaps it makes sense to heed the recommendation and get away from being categorical. Everyone reacts too violently to her. Well, add “because” to each item.
1. The program tries to reinvent the object model or “fix” language features.
Try searching for a class called Object. If you succeeded, then this is a sure sign that the author is trying to invent an object model (most often this comes from a lack of understanding). We can safely assume that his “corrections” will not stop there. Our advice when meeting with such a developer: turn off the phone and change the mailing address.
2. The code uses custom global variables.
A search by the word code “global” or “$ GLOBALS” can reveal a lot of interesting things, for example this:
global $ database, $ my, $ mainframe;
If you can tell me what is contained in the last two variables, you are either closely acquainted with the author of the lines of the program, where this example is taken from, or crazy. The probability of the second option increases if you can say what value any of these variables will take in different periods of time. In short, a sure sign that shit code came to you - global variables.
3. Mixed html and SQL.
If you can find HTML code with SQL in one of the project files, you should know that this is shitty code.
4. The class knows too much.
Find the largest class in the project by file size. Look at its name. Can you unambiguously determine by him what he is doing? Look at the methods of this class. Are they related by a common sense? If you clearly answered “no” to both questions, run away with screams from such a developer.
5. Too many public or static properties.
If you find many properties declared as “public static”, multiply your crap conclusions by three.
6. Several levels of inheritance.
You should escape from more than two levels of inheritance in PHP code, like from a plague. Of course, there can be an exception to any rule. For example, if you have no doubt that your developers are as professional as the developers of ZendFramework. If you find the proper use of more than two levels of inheritance in lesser-known (unknown to anyone) products - you are very lucky.
7. The authors try to use design patterns.
To find out if the authors had such a desire - look for the words "factory", "decorator", "strategy". If you find something, the task is 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. You are very lucky. Before you - not shit code.
8. Changing the error-level leads to increased talkativeness of the application.
Search the error_level files. If successful, replace the value with E_STRICT. If after that a bunch of warnings and notifications (notice) appeared in the application, then get acquainted - crap.
9. In the directory structure there is a folder called "core".
It, as a rule, contains “common” parts for the application. Despite such a good intention, most often it is a sign of crap.
10. The application uses its own template engine.
Beware, this is really scary. These are the guys who will invent the wheel again and again. Here is the shitty code. Ignore this warning and they will soon invent a for loop for you.
The article is a free translation of this .
UPD It seems that the tone of the article seemed too harsh to jurors, minus karma. I apologize, my dears (behind the scenes laughter of Regina Dubovitskaya).
UPD2. Perhaps it makes sense to heed the recommendation and get away from being categorical. Everyone reacts too violently to her. Well, add “because” to each item.