Do not judge someone else's code strictly
It so happened that most of my conscious life I program in PHP. Our brain, perceiving information from any source, does this without interruption from the authority of this source. Roughly speaking, if you love PHP - you automatically added credibility points to the author of this article, and if you do not like - they automatically took them away. This process takes place at an unconscious level and is essentially a prism of perception, which on the one hand protects us from falling into an endless analysis of information of any degree of authority, but on the other hand limits us in the search for new, more relevant information. The worst part is that the credibility of the source is rarely checked at a conscious level (because it takes time and resources in the form of precious calories), I can be with the same probability a plus developer, a housewife-cook, a plumber without a princess, or genetically modified cat. Do not judge my article strictly, I have paws.
The same applies to reading someone else's code: if its author sits on the left hand of your throne, has been working in your company for 10+ years and earns one zero more than you, this is absolutely not the same as the author who was fired for something- that’s bad, and you were hired in his place. But in fact, the code here and there is just a set of bytes that would be useful to evaluate without reference to the authority of the source.
When we read someone else's code, we can be visited by a wide variety of emotions: admiration, laughter, irritation, disappointment, complete rejection. It is useful to know that the manifestation of any emotions in any context is an automatic response of the lower (first) level of the nervous system, formed in an evolutionary way, necessary in a primitive environment. The main task of such an answer, in the case of a “negative” emotion, is to launch the “fight or run” mechanism of action with one single goal - to survive. In our current office environment, when analyzing someone else’s code, such an answer becomes rather useless and even harmful, because you spend precious time and resources on it, plus you pollute your brain with neurotransmitters that lower your quick wits for the sake of reaction speed. The good news is that this answer can be reprogrammed. You can suppress negative emotional reactions, or you can inventory them, for example, laugh where you were angry before. Laughter, unlike anger, throws into the brain good, tasty, useful neurotransmitters that give pleasure, reinforce experience and motivate you to continue working.
In order to reprogram the emotion, you need to mentally go into a meta position in order to evaluate your own situation, evaluate yourself instead of condemning someone else's code. Why does this piece of someone else's code disgust me? Is it really that the amateur wrote it, and now I have to suffer so good and experienced? If I am so good and experienced, then why am I having problems in order to understand someone else’s code and rewrite it as I see fit? Maybe I just do not have enough RAM to realize this noodle? Perhaps the author of this piece knows something that I don’t know?
Modern development tools allow you to transform someone else’s code into more understandable and enjoyable structures almost on the fly. A function or variable is poorly named - ctrl + shift + R and in a couple of seconds it is called for good. Tabs instead of spaces, inconveniently, unusually scattered indents and opening braces in the Egyptian style - ctrl + shift + F and formatting restored! Comment is redundant or outdated - ctrl + D and it is not. If you change the prism of perception, reading someone else's code can turn into a fun interactive detective game.
Code is just a tool. No matter how badly and horribly he was written, at a specific time and in a particular place he successfully solved a specific problem, which means he is already "justified." Something has changed in business requirements, something has not been taken into account - the code has broken or become out of date, and this is normal. The code has the ability to evolve in a variety of ways: and gradually, overgrown with layers and revolutionary, writing from scratch. Of course, it is good when the programmer foresees the future and at the initial stages lays in the code the possibilities for its further development. But this ax is sharp on two sides, you can make a mistake with predicting the future, the future may not come at all, and time and resources will be irretrievably lost. It is important to understand the code to what degree of quality is required of you. If this is a huge distributed system, the modules for which are programmed by your colleagues from all over the world in companies weakly connected with yours, then yes, it makes sense to use fashionable patterns, wrap modules in service containers even where you cannot imagine why this is need to. But if this is a small local CRM for one company, the modules of which are so rigidly dependent on each other that disabling any module essentially stops the entire system from working ... in this case, it is justifiable to call other people's methods directly, this will reduce the number of classes and facilitate your operational memory and reduce the time to debug problems. But here a situation arises when a small local CRM turns into something expandable that your company wants to put in the public domain and sell. Business requirements have changed. Should the programmer be blamed for not foreseeing this?
Code is just a tool, but its creation is pure creativity. Any problem can be solved by an infinite number of the most diverse ways. Some of them are more productive than others - an example of an objective assessment. Some of them are more readable than others - an example of subjective assessment. Even if you convince the whole office that some piece of code is not readable, there will still be at least one author who disagrees with you. The standardization of the code is aimed at transforming pure creativity into the most routine set of actions so that it is easier for other programmers to understand your code. That is, in fact, so that you can be replaced by another specialist, more docile and cheaper. And after a couple of decades, it’s completely artificial intelligence. It is worth remembering that if some standard is contrary to common sense, it may make sense to violate it in some places, or even completely abandon it or replace it with another, more suitable one.
Mature standards sell themselves from the position of "when choosing a standard, pay attention to the popularity of the community." I wonder how they sold themselves when they just came out. The main idea is that the popularity of a particular standard is not a factor that you would like to consider first of all when choosing. Popularity and communities are very inert and can for many decades reject new, better standards. Especially if they are revolutionary.
Particular attention is paid to standards that have thoroughly established themselves in culture simply because they arose earlier than other similar standards. A canonical example is the holy war between the layouts of QUERTY and Dvorak. The second, obviously, is better, but the first holds a blow (remains more popular) simply due to the critical mass of users who do not want to retrain on a new one.
Similar examples are found all along and in the culture of programming. The PSR standard stands for 4 spaces instead of tabs, ignoring the obvious fact: the development environment of most PHP programmers has changed from console editors to full-fledged IDEs, in which tabbing is more convenient in many ways: it’s easier to delete it by pressing Backspace once, and you can configure individual lengths Tabs to taste.
When applying this or that standard, ask the question: to whom do you make it more convenient? Who is more uncomfortable? Who will benefit from the rule “name the names of the methods of the lowerCamelCase”? Obviously only to those who are used to calling them that. Everyone else will become uncomfortable, they will have to adapt, and this loss of time and resources is absolutely from scratch, given the fact that
a) now we have magical IDEs that highlight different elements of the code in different colors,
b) programmers have the ability to jump from project to project, coding standards in which may vary.
Personally, when developing my projects I use:
I have no problem distinguishing a class name from a method name, since the first is a noun and the second is a verb. In addition, the backlight helps out. But this is my personal taste, I do not impose it on anyone. This is a personal prism of perception, it is individual for each individual head. Someone was “lucky” to immediately plunge into the popular standard, someone was “unlucky” to start their career with alternative ones, and someone generally developed their own. I’m leading you to the fact that instead of retraining others, it may make sense to retrain yourself to perceive code in any standards. Or even beyond standards.
Of course, the adherents of standardization in this place will be outraged and throw me many reasons against. This article is not for them, I am writing it for those who are interested in understanding the essence of things, trying to imagine what the author really had in mind and what purpose he pursued.
The trigger that causes the vomiting impulses in the vast majority of programmers (an example of a subjective assessment). It never seemed strange to you that it’s often easier for us to rewrite all the code from scratch than to understand someone else’s? In any other industry, we act differently: first we learn to read, then to write; first use (electrical appliances, buildings), then design them. It seems to me the whole point is in our education (specifically in the field of programming). We are taught to achieve the goal in the most direct and quick way, using some freshly acquired knowledge. As a result, we combine them (knowledge) exactly until “it” works, test a little and send it to the teacher for moderation. In my opinion, it would be nice to add an additional step to this process, in which we compare our code with the master code, which, although it is not ideal and the only correct one, but provides an alternative solution, often more optimal and readable.
As for the trigger, to turn it off, it’s enough just to mentally put yourself in the place of the customer, who has been watching departing-coming programmers all his life, claiming that the work of their predecessors is feces and you need to rewrite everything to make it good. The customer does not have the competence to find out whether you are telling the truth or just be lazy to understand someone else's code. To gain his trust in such a matter, you should delve into someone else's code and find a couple of giant security holes and demonstrate them to the customer. But even in this situation, from a business point of view, it may be more profitable to “harden”. Especially if it is an outsourcing with specific deadlines and money. Should the programmer be blamed for this?
Whose, write me with the letter I. Instead of breakfast, drink coffee and butter through a blender.
Look deeper, think wider, look for alternatives. Never stop developing.
The same applies to reading someone else's code: if its author sits on the left hand of your throne, has been working in your company for 10+ years and earns one zero more than you, this is absolutely not the same as the author who was fired for something- that’s bad, and you were hired in his place. But in fact, the code here and there is just a set of bytes that would be useful to evaluate without reference to the authority of the source.
When we read someone else's code, we can be visited by a wide variety of emotions: admiration, laughter, irritation, disappointment, complete rejection. It is useful to know that the manifestation of any emotions in any context is an automatic response of the lower (first) level of the nervous system, formed in an evolutionary way, necessary in a primitive environment. The main task of such an answer, in the case of a “negative” emotion, is to launch the “fight or run” mechanism of action with one single goal - to survive. In our current office environment, when analyzing someone else’s code, such an answer becomes rather useless and even harmful, because you spend precious time and resources on it, plus you pollute your brain with neurotransmitters that lower your quick wits for the sake of reaction speed. The good news is that this answer can be reprogrammed. You can suppress negative emotional reactions, or you can inventory them, for example, laugh where you were angry before. Laughter, unlike anger, throws into the brain good, tasty, useful neurotransmitters that give pleasure, reinforce experience and motivate you to continue working.
In order to reprogram the emotion, you need to mentally go into a meta position in order to evaluate your own situation, evaluate yourself instead of condemning someone else's code. Why does this piece of someone else's code disgust me? Is it really that the amateur wrote it, and now I have to suffer so good and experienced? If I am so good and experienced, then why am I having problems in order to understand someone else’s code and rewrite it as I see fit? Maybe I just do not have enough RAM to realize this noodle? Perhaps the author of this piece knows something that I don’t know?
Modern development tools allow you to transform someone else’s code into more understandable and enjoyable structures almost on the fly. A function or variable is poorly named - ctrl + shift + R and in a couple of seconds it is called for good. Tabs instead of spaces, inconveniently, unusually scattered indents and opening braces in the Egyptian style - ctrl + shift + F and formatting restored! Comment is redundant or outdated - ctrl + D and it is not. If you change the prism of perception, reading someone else's code can turn into a fun interactive detective game.
Code is just a tool. No matter how badly and horribly he was written, at a specific time and in a particular place he successfully solved a specific problem, which means he is already "justified." Something has changed in business requirements, something has not been taken into account - the code has broken or become out of date, and this is normal. The code has the ability to evolve in a variety of ways: and gradually, overgrown with layers and revolutionary, writing from scratch. Of course, it is good when the programmer foresees the future and at the initial stages lays in the code the possibilities for its further development. But this ax is sharp on two sides, you can make a mistake with predicting the future, the future may not come at all, and time and resources will be irretrievably lost. It is important to understand the code to what degree of quality is required of you. If this is a huge distributed system, the modules for which are programmed by your colleagues from all over the world in companies weakly connected with yours, then yes, it makes sense to use fashionable patterns, wrap modules in service containers even where you cannot imagine why this is need to. But if this is a small local CRM for one company, the modules of which are so rigidly dependent on each other that disabling any module essentially stops the entire system from working ... in this case, it is justifiable to call other people's methods directly, this will reduce the number of classes and facilitate your operational memory and reduce the time to debug problems. But here a situation arises when a small local CRM turns into something expandable that your company wants to put in the public domain and sell. Business requirements have changed. Should the programmer be blamed for not foreseeing this?
Standardization
Code is just a tool, but its creation is pure creativity. Any problem can be solved by an infinite number of the most diverse ways. Some of them are more productive than others - an example of an objective assessment. Some of them are more readable than others - an example of subjective assessment. Even if you convince the whole office that some piece of code is not readable, there will still be at least one author who disagrees with you. The standardization of the code is aimed at transforming pure creativity into the most routine set of actions so that it is easier for other programmers to understand your code. That is, in fact, so that you can be replaced by another specialist, more docile and cheaper. And after a couple of decades, it’s completely artificial intelligence. It is worth remembering that if some standard is contrary to common sense, it may make sense to violate it in some places, or even completely abandon it or replace it with another, more suitable one.
Mature standards sell themselves from the position of "when choosing a standard, pay attention to the popularity of the community." I wonder how they sold themselves when they just came out. The main idea is that the popularity of a particular standard is not a factor that you would like to consider first of all when choosing. Popularity and communities are very inert and can for many decades reject new, better standards. Especially if they are revolutionary.
Particular attention is paid to standards that have thoroughly established themselves in culture simply because they arose earlier than other similar standards. A canonical example is the holy war between the layouts of QUERTY and Dvorak. The second, obviously, is better, but the first holds a blow (remains more popular) simply due to the critical mass of users who do not want to retrain on a new one.
Similar examples are found all along and in the culture of programming. The PSR standard stands for 4 spaces instead of tabs, ignoring the obvious fact: the development environment of most PHP programmers has changed from console editors to full-fledged IDEs, in which tabbing is more convenient in many ways: it’s easier to delete it by pressing Backspace once, and you can configure individual lengths Tabs to taste.
When applying this or that standard, ask the question: to whom do you make it more convenient? Who is more uncomfortable? Who will benefit from the rule “name the names of the methods of the lowerCamelCase”? Obviously only to those who are used to calling them that. Everyone else will become uncomfortable, they will have to adapt, and this loss of time and resources is absolutely from scratch, given the fact that
a) now we have magical IDEs that highlight different elements of the code in different colors,
b) programmers have the ability to jump from project to project, coding standards in which may vary.
Personally, when developing my projects I use:
- CamelCase for naming classes and methods
- $ CamelCase for naming variables containing an instance of an object
- $ snake_case for naming variables containing simple types
I have no problem distinguishing a class name from a method name, since the first is a noun and the second is a verb. In addition, the backlight helps out. But this is my personal taste, I do not impose it on anyone. This is a personal prism of perception, it is individual for each individual head. Someone was “lucky” to immediately plunge into the popular standard, someone was “unlucky” to start their career with alternative ones, and someone generally developed their own. I’m leading you to the fact that instead of retraining others, it may make sense to retrain yourself to perceive code in any standards. Or even beyond standards.
Of course, the adherents of standardization in this place will be outraged and throw me many reasons against. This article is not for them, I am writing it for those who are interested in understanding the essence of things, trying to imagine what the author really had in mind and what purpose he pursued.
Ability to understand someone else's code
The trigger that causes the vomiting impulses in the vast majority of programmers (an example of a subjective assessment). It never seemed strange to you that it’s often easier for us to rewrite all the code from scratch than to understand someone else’s? In any other industry, we act differently: first we learn to read, then to write; first use (electrical appliances, buildings), then design them. It seems to me the whole point is in our education (specifically in the field of programming). We are taught to achieve the goal in the most direct and quick way, using some freshly acquired knowledge. As a result, we combine them (knowledge) exactly until “it” works, test a little and send it to the teacher for moderation. In my opinion, it would be nice to add an additional step to this process, in which we compare our code with the master code, which, although it is not ideal and the only correct one, but provides an alternative solution, often more optimal and readable.
As for the trigger, to turn it off, it’s enough just to mentally put yourself in the place of the customer, who has been watching departing-coming programmers all his life, claiming that the work of their predecessors is feces and you need to rewrite everything to make it good. The customer does not have the competence to find out whether you are telling the truth or just be lazy to understand someone else's code. To gain his trust in such a matter, you should delve into someone else's code and find a couple of giant security holes and demonstrate them to the customer. But even in this situation, from a business point of view, it may be more profitable to “harden”. Especially if it is an outsourcing with specific deadlines and money. Should the programmer be blamed for this?
Conclusion
Whose, write me with the letter I. Instead of breakfast, drink coffee and butter through a blender.
Look deeper, think wider, look for alternatives. Never stop developing.
All Articles