30 bad advices for PHP Developers

So let’s go:

  1. Be sure to write the layout directly in php scripts and display it only through echo (for some reason, this language construction is needed).
  • Try to use as much echo as possible in your projects, remember that it was invented by cool language developers, which you are far from.
  • Write the database connection parameters in each file where necessary, and do not store information anywhere about where and what configurations are registered – let everyone else develop to your level.
  • Create as many database connections as possible in different parts of the project, it is desirable that many of them be called at the same time, in general, create a new connection to the database every time you run any function.
  • Do not use standard language functions – write your own, they will work 100 times better and exactly the way you need.
  • Include all project files anywhere in the project, even if you only need one function.
  • Use the GLOBALS array – you can’t do without it at all, the language developers came up with it for your convenience, but the problems with the end of the cache are problems of the server, not the language.
  • Call functions and use cycles right in the layout, this is the output of information, there is no way without functions.
  • In no case do not use mysql parameters, write $_GET, $_POST variables directly into the request so as not to waste extra CPU time, it is very important for us.
  1. Duplicate the same method in all classes every time you need it, forget about inheritance, it’s a thing of the past.
  1. Use only static methods and properties, no need to create objects, classes are not designed for that.
  1. The methods of classes working with the database must return a RESOURCE and nothing else, it is better to use while every time you receive data from the class.
  1. Be sure to do sql queries in cycles, this is very important, otherwise how will you get all the records from the table?
  1. Store the date and time in varchar fields, because the datetime field has some strange format of its own.
  1. Create a field for yourself in the table, where for each entry you will add all the changes with the entry through <br />, and be sure to do so. In no case do not create a separate table of logs, why do we need an extra file on the disk.
  1. Don’t create many cells in database tables, better use seialize and forget about encoding when saving, if unserialize throws an error every time, just ignore it.
  1. In general, ignore ALL errors in the project, turn off error_reporting – it only gets in the way, don’t be nerds.
  1. Never, you hear, never check a variable for existence, just display it directly in the template, after point 17, Notice is no longer a problem for you.
  1. Write only this way for($i=0; $i<count($arr); $i++), because counting the number of elements in an array at each iteration is good, and post-increment works much faster, and those who say the opposite simply don’t know what he is talking about. And you need to sort through a large array first, because it’s faster this way.
  • Do not use parsing in any form, it is very bad, it is better to download the entire page along with the layout and save it to the database directly as received, do not waste time on parsing, especially since using DomDocument slows down the project very much, and you still need to learn it, but you have no time – you need to write a project.
  • Store all information about users in one table – authorization data, personal data, home addresses and phone numbers, places of work, and generally store any information in one table and do not forget about serialize
  • Do not use indexes and keys in the database, and even more so the relationships between tables, this is very bad.
  • Never use reference tables, it is better to duplicate everything in one column, especially if the column contains large and frequently repeated data.
  • Have you heard about the standard for naming functions and methods? Forget! Who ever came up with the idea that there should be some logic in the names of functions, and functions with the names a(), b(), aa() are much shorter to call.
  • Make functions as large as possible, if the programmer is too lazy to read what the function does – he is a bad programmer.
  • Never write comments anywhere, because true progers don’t need them, in the worst case, you can write a comment like /*this is a() function, it takes two variables $a and $b*/ for completely stupid ones.
  • Functions should take as many parameters as possible, do a bunch of different actions with them, and always return an unpredictable result in order to still force progers to read their source codes.
  • Since we have already decided not to use inheritance, to re-write functions from other classes, we need to supplement this with the fact that the class must be at least 1000 lines long, and the larger it is, the better.
  • In order to get a really big class, you need to select a whole line for each parenthesis, you need to create a lot of class properties, just in case, and we also remember that in no case should you use standard php functions – we always write our own.
  • And the last thing, let’s say that you need a script whose actions change depending on the date (what if), be sure to write this date directly into the script so that you can enter and correct it manually every time to always keep the script under control.

Thank you for your attention!

But how can you avoid these mistakes?

This is exactly what PSR advises.

Of course, but not in cases with loops and conditions. see PSR-2 5.1-5.6

how to do the layout correctly so that it doesn’t work out like in 1 and 2?

Create separate template files, which by the way can be connected suddenly without using echo

In general, there are a lot of ways to display information in a template without echo

For example, I use DOM for such purposes.

Those. I have a pure html template in which pseudo-variables are placed, and the template engine, catching the template and knowing how many values ​​the variable has, simply parses the desired layout element as many times as necessary, and then displays the result through saveHTML. As a result, we have clean templates in which there is only layout, clean scripts in which there is no layout and only 1 echo for the entire project consisting of several hundred pages and happy coders and layout designers, since neither of them are afraid that someone might drop the project or cover the layout. For details, I advise you to look at the good old xTemplate (although now there are more powerful analogues in general with complete code separation)

Turned off E_NOTICE on the prod – display_errors of course

Of course, and then you can safely put non-existent variables directly into the template and not fool yourself with unnecessary information like Notice, why did you come up with checks for existence and checks for emptiness, they only complicate the code.

Leave a Reply

Your email address will not be published. Required fields are marked *