Factories for workers, Code for programmers!
Over the years of professional activity, I formed the opinion that for the most part the program code is written “on the knee”, “in a hurry”, “on pain of the deadline” and so on. Refactor this code is not that even not always - but almost never. Such code can be difficult to perceive later. I do not complain, I understand that this is the state of things and it is unlikely to change drastically.
But! There are things (by itself, long known, like most others) that developers often unforgivably forget, but who are able to make them, as well as other people, happier - when it comes time to dig out the code that was written sometime.
')
1. Give friendly names to your functions, methods, classes, and variables. When the code is replete with names like "s", "ss" and "sss" - and each of these variables has its own type and purpose - I want to howl like a wolf, especially when they are constantly used in the method with a length of five hundred lines. Do not use abbreviations , unless they are 100 percent understandable to everyone (for example, it is foolish to call a DOMDocument class variable “ document_object_model_document ”, however, it is often not good to call the CustomerCollection class object cc : if this variable is used in a long method , there is a risk of getting confused). Modern development tools provide many opportunities for autocompletion, so you should not save on characters, reducing the clarity of the code. It is not necessary to give two methods names that differ in one or two letters (sometimes the choice of this letter is completely random and defies logic). It often happens that after it is impossible to understand in which cases one should be used, and in which other - the method, one has to search the use case code to find out what is what. The name must reflect the value of the object!
2. Divide and conquer. Divide the program into smaller parts. It is clear that when you do one rather voluminous task, there is a temptation to write and write a sheet of one function until the task is completed. But you yourself will not notice how first you copy one part, then the other - and the program runs the risk of becoming a complete copy-paste itself.
3. Try to avoid long lists of parameters in functions and methods . Usually it should be limited to no more than 3 (however, this is my personal opinion and you can establish your own agreements). It often happens that you want to add a parameter to a function that is not needed there, which will only unnecessarily complicate the function calls. Look - maybe it is possible to select a separate function that will do a small part of the work for which this new parameter is responsible. Omnipotent, universal functions are often bad because of their solidity.
4. Write comments. Yes. Write comments - to methods, functions and classes. To unobvious places in the code, to "temporary" "patches" (they usually live longer than you think and may later lead to extreme bewilderment). If you are commenting on the signature of a method or function, change the comment without fail when the signature itself changes, especially if your IDE relies on comments for all kinds of autocomplete (for example, IDE for PHP behaves exactly like this).
5. Try to avoid long methods and large files with source code. They are difficult to navigate. Refactor: you can probably remove duplication, remove the extra responsibility from the code (by moving it into a separate block) - reduce the volume of the source code.
But! There are things (by itself, long known, like most others) that developers often unforgivably forget, but who are able to make them, as well as other people, happier - when it comes time to dig out the code that was written sometime.
')
1. Give friendly names to your functions, methods, classes, and variables. When the code is replete with names like "s", "ss" and "sss" - and each of these variables has its own type and purpose - I want to howl like a wolf, especially when they are constantly used in the method with a length of five hundred lines. Do not use abbreviations , unless they are 100 percent understandable to everyone (for example, it is foolish to call a DOMDocument class variable “ document_object_model_document ”, however, it is often not good to call the CustomerCollection class object cc : if this variable is used in a long method , there is a risk of getting confused). Modern development tools provide many opportunities for autocompletion, so you should not save on characters, reducing the clarity of the code. It is not necessary to give two methods names that differ in one or two letters (sometimes the choice of this letter is completely random and defies logic). It often happens that after it is impossible to understand in which cases one should be used, and in which other - the method, one has to search the use case code to find out what is what. The name must reflect the value of the object!
2. Divide and conquer. Divide the program into smaller parts. It is clear that when you do one rather voluminous task, there is a temptation to write and write a sheet of one function until the task is completed. But you yourself will not notice how first you copy one part, then the other - and the program runs the risk of becoming a complete copy-paste itself.
3. Try to avoid long lists of parameters in functions and methods . Usually it should be limited to no more than 3 (however, this is my personal opinion and you can establish your own agreements). It often happens that you want to add a parameter to a function that is not needed there, which will only unnecessarily complicate the function calls. Look - maybe it is possible to select a separate function that will do a small part of the work for which this new parameter is responsible. Omnipotent, universal functions are often bad because of their solidity.
4. Write comments. Yes. Write comments - to methods, functions and classes. To unobvious places in the code, to "temporary" "patches" (they usually live longer than you think and may later lead to extreme bewilderment). If you are commenting on the signature of a method or function, change the comment without fail when the signature itself changes, especially if your IDE relies on comments for all kinds of autocomplete (for example, IDE for PHP behaves exactly like this).
5. Try to avoid long methods and large files with source code. They are difficult to navigate. Refactor: you can probably remove duplication, remove the extra responsibility from the code (by moving it into a separate block) - reduce the volume of the source code.
Source: https://habr.com/ru/post/53263/
All Articles