Works great in theory, but then people inevitably forget to update the comments and code gets out of sync with what the comment says. At which point you’re in even worse situation than not having any comments at all.
Sure, yet the fact that this happens regularly is the reality of the situation. Simply wagging your finger and saying it’s the fault of people who don’t update the comments isn’t really solving anything. Not to mention the fact that people might accidentally update the comments in a wrong way while being well intentioned. Since there’s no way to validate that the comments are correct, it’s very easy for mistakes to creep in. Anybody who’s done actual software development would understand this problem.
This is why you have style guides, policies and safeguards, with others checking PRs as they go through to catch this sort of stuff.
Plus I’m not saying everything should be commented. By default things should be explainable through the code and making sure variable and method names are descriptive, along with strong typing if your language has it.
Comments are there for when the code itself is not enough. But you’re right shit always creeps in eventually regardless of the best intentions. Which is why teams need tech debt breaks where no new features are added and they go through the code fixing the niggly things that haven’t been worth fixing whilst doing other features, and ensuring critical sections (the kind that usually have comments on them) are still working as intended and described accurately.
Again, I’m perfectly aware of how the process is supposed to work and what purpose comments serve. This is the exact same argument people make when complaining that everybody is doing Agile wrong. What I’m explaining to you, as another senior dev in the industry, is that a lot of the time people start cutting corners because they have deadlines, or they don’t understand the code because it was written a long time ago by somebody who doesn’t work at the company anymore, or a myriad other reasons. Keeping comments in sync with the code is not trivial in practice, and it’s often done poorly.
Works great in theory, but then people inevitably forget to update the comments and code gets out of sync with what the comment says. At which point you’re in even worse situation than not having any comments at all.
If you’re ever the one updating code with comments and not ensuring they match to the new updates, you are the problem, the comments are not.
Sure, yet the fact that this happens regularly is the reality of the situation. Simply wagging your finger and saying it’s the fault of people who don’t update the comments isn’t really solving anything. Not to mention the fact that people might accidentally update the comments in a wrong way while being well intentioned. Since there’s no way to validate that the comments are correct, it’s very easy for mistakes to creep in. Anybody who’s done actual software development would understand this problem.
This is why you have style guides, policies and safeguards, with others checking PRs as they go through to catch this sort of stuff.
Plus I’m not saying everything should be commented. By default things should be explainable through the code and making sure variable and method names are descriptive, along with strong typing if your language has it.
Comments are there for when the code itself is not enough. But you’re right shit always creeps in eventually regardless of the best intentions. Which is why teams need tech debt breaks where no new features are added and they go through the code fixing the niggly things that haven’t been worth fixing whilst doing other features, and ensuring critical sections (the kind that usually have comments on them) are still working as intended and described accurately.
This is from a senior dev in the industry.
Again, I’m perfectly aware of how the process is supposed to work and what purpose comments serve. This is the exact same argument people make when complaining that everybody is doing Agile wrong. What I’m explaining to you, as another senior dev in the industry, is that a lot of the time people start cutting corners because they have deadlines, or they don’t understand the code because it was written a long time ago by somebody who doesn’t work at the company anymore, or a myriad other reasons. Keeping comments in sync with the code is not trivial in practice, and it’s often done poorly.