How to write code so that your colleagues do not swear

    Imagine one single thing that will make your code more understandable, and it will also help you to understand someone else’s code much easier and you will less “mess up” someone else’s code that was written before you joined the company. And the best thing is you will always understand whether it is worth changing it or better not to touch it. Presented ?!

    The beginning is too promising and you have already felt some kind of divorce.

    Now, seriously.

    I write code both 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, there are thoughts: “Why did I write like this here, is that wrong?” And suddenly, if I want to change, then a situation may arise that now, something is working 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 from all the options I chose exactly the implementation that I stopped at?”. Especially if you work in a team. I had a situation that the piece of code that another person wrote did not fully implement what I needed and now I have a logical question: “Why did he do this?”, But we can’t remember everything and logically received the answer: “ I don’t remember why. Something didn’t grow together there. ” And you find yourself in a stalemate situation, the option that is now available and on the other hand are afraid of starting to rewrite you, because you don’t know where the problem will come from, maybe you will encounter the same insoluble problem that your colleague faced, or maybe you will not . Who knows this now ?! And that leads to

    So I believe that writing the reason for choosing an option gives certain bonuses.

    1. Even when you work alone, you can immediately understand if you know the reason. You just got dumb when you wrote this code or it is an adequate code, given the context.
    2. You grow up as a programmer, and you can change the decision that you once made out of inexperience, because you know why it is here.
    3. Over time, the very reason that such a code is written can “sink into oblivion” and now when you see this, you understand that you can part with it with a quiet mind, if you don’t write it, then it will remain here, afraid to hurt something.
    4. You can look at the old code written before you in a new way. If earlier, with an arrogant gaze, you just scummed him, now you understand that in the situation that the programmers were before you, this was a very correct decision.
    5. Saves from the situation when you clean, the crutch decision that was before you, and it turns out that you opened the pandora’s box, because only this crutch restrained from universal death.
    6. When you write why, another developer who sees this will be able to 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 reasons of the people who at a particular moment in a particular situation it was taken to evaporate the next day.

    Also popular now: