• MrScottyTay@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    6 hours ago

    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.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      5 hours ago

      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.