Programming culture

PSR standards. Ensure readability and portability for your code.
Principles of SOLID ( wiki ).
Classical: DRY , KISS ( habr + YAGNI).

What I would like to add specifically about PHP:

• PHP, in place, is a rather unreliable language. Always use a strict comparison (===,! ==), unless it is absolutely necessary to have a non-strict (==,! =).
• Cover everything that is possible with tests: it is really simple and saves a lot of time searching for errors.
• If there is no clear TK for any component, then write immediately with an eye to the expansion, make at least blanks for those methods that may be needed.
• Always, always, always comment on the code and update the comments at the slightest sneeze. As soon as the project grows, you will say thanks to yourself and automatic input of these comments in the IDE.
• Checks. Do them wherever you see fit. Remember that if they start to slow down the code, you can easily get rid of them.
• Checks # 2. Always check the input values ​​(input) for expected. If you break, first of all they will break it here.
• Checks # 3. If your check fails - be sure to output the appropriate message. It will save a billion nerves when some of the checks suddenly fall, and there are only ten of them, and it is not clear which one fell.
• Logs. If you can write them - write. If you write some kind of apish - the log will remain the only place where you can catch the fault.
• The official docks for PHP are not particularly full of exceptions, but in fact it is quite a powerful tool. Instead of trigger_error, always create an exception. Exceptions can be inherited; in PHP, again, this is not very common, but for me personally, for example, it is convenient to have a whole system of exceptions in which I can understand the error by the name of the exception class.
• Feel free to use other people's development. Remember that separately scattered on the web pieces of code and classes are usually the property of the site govnokod.ru, but libraries that implement rich functionality, have an equally rich version history and found on the github will most likely be very useful.
• Do not be afraid to write classes, do not be fooled by calls to optimize the code until it works. Usually, the first problem of a newbie who has learned to write is over-optimization where it is not needed, the fear of writing a class because it takes a long time to load, etc. As soon as it comes to mind to implement the component as a function or call the variables shorter, to quickly worked - drive them away, remember that the most important thing in the code is its readability and incoherence (see the next paragraph). If you can return to the code in three months, read the comments and understand how it works, then you can optimize it at the same time. If you have written optimized code that cannot be read, then you will not be able to really expand it.
• Write loosely coupled components. The database should deal only with the database, the FTP connection class should not know if it runs on Windows or Linux - if such a question arises, then you need to write the base class and inherit the Linux and Windows subclasses from it so that the component loader itself decides which he needs This will make it easy to "remove" the class and replace it without breaking the entire application and making changes only within one class (for example, if the OS on the hosting changes suddenly). (Generally, FTP is a bad example, but I hope it’s clear what I’m talking about).
• There is nothing terrible to sketch "approximate" code, which will work through time and somehow, to make some fittings. However, it should be immediately rewritten as soon as you understand what you want from it, because as soon as something starts to depend on its public interface, you will have dependency hell, and a lot of time can be spent later on switching to the updated interface. .
• As a programmer, you have a limited set of resources: concentration, the number of objects in the "RAM", fatigue, free time. Your task is to write such code in order to use them to the minimum - for this you need clear standards for writing code, minimal connectivity and so on - this allows you to direct resources exactly where they are needed, and not to spray them all over the project. The project can expand indefinitely, your physical capabilities - no.
• Read. The best of all are the manuals for the frameworks: see how the code is written, how it is structured, what methods exist, and most importantly, what will be written next to what is happening in one or another piece of code.
• And the last thing: in any project, a developer or consultant may suddenly appear. Write the code so that he can understand it without any problems: clearly and clearly.