How to write code so that your colleagues do not matter

Imagine one single thing that will make your code more understandable, as well as help you much easier to understand someone else's code and you will less “smear” someone else's code that was written before you came to the company. And the best thing is that you will always understand whether to change it or better not to touch it. Presented?

Too promising start and you already felt some kind of divorce.

Now seriously.

I write code for myself on my own project and in a company where I program more than one. And I began to notice that even when I work alone and return to the old section of the code, then there are thoughts: “Why did I even write this here, because it’s wrong?”. And suddenly, if I want to change, then there may be a situation that now, something is wrong and the decision that I made when I wrote that old code was optimal.
')
So it is important to write in the comments “Why”, “Why did I make that decision when I programmed?”, “Why did I choose the implementation I chose from all the options?”. Especially if you work in a team. I had a situation that a section of the code that the other person had written does not fully implement what I need and now I have a logical question: “Why did he do that?”, But we cannot remember everything and logically received the answer: “ I do not remember why. Something did not grow there. ” And you find yourself in a stalemate. The option that you have now is not suitable for you, and on the other hand you are afraid to start rewriting, because you don't know where the problem will come from, maybe you will encounter the same unsolvable problem that a colleague has encountered, and maybe not. . Who knows that now ?! And this leads to the fact that some parts of the code become "untouchable", you are afraid to touch them.

So I think that writing a reason for choosing an option gives certain bonuses.

1. Even when you work alone, knowing the reason you can immediately understand you are just stupid when writing this code or it is an adequate code, taking into account the context.
2. You grow as a programmer and you can change the decision that you once made because of inexperience, because you know why it is there.
3. Over time, the very reason why such code was written could “sink into oblivion” and now seeing this, you realize that you can part with it with peace of mind, but if you don’t write it, then it will remain here, afraid to damage something.
4. You can take a fresh look at the old code written before you. If earlier with a haughty look only smeared it, now you understand that in that situation in which programmers found themselves before you, this was a very correct decision.
5. It saves from the situation when you remove the crutch solution that came before you, and it turns out that you opened the pandora's box, because only this crutch was holding back from total death.
6. When you write why, another developer who sees this can rewrite, knowing how to solve the problem that you solved more effectively.

In conclusion, I want to say. The code remains printed for a long time, but the thoughts and causes of people who at a particular moment in a particular situation accepted it evaporate the next day.