• EnderMB@lemmy.world
    link
    fedilink
    arrow-up
    28
    ·
    1 year ago

    Comments don’t describe the code. They describe the decision to use this business logic.

    If you stick to good engineering practices, like small methods/functions, decoupling, and having testable code, you don’t often need many comments to show what your code does. I always recommend a method signature, though, because you can save a few seconds by just saying that a block of code does, rather than me needing to read exactly how you turned one dict into another dict…

    • MrSqueezles@lemm.ee
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      I agree for inline code comments, like, “# Save the sprocket”, right above the line that saves the sprocket. Does this include documentation? Because when I see a prepareForSave function that references 10 other functions and I just want to know, “Is this mutating and how is it preparing for save and when should I call it?”, having the author spend 15 seconds telling me is less time consuming than me spending 5 minutes reading code to find out. Anyone who has read API docs has benefited from documentation.

      • EnderMB@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        No, commenting a function should be commonplace, if not only so that your IDE/editor can use the documentation when the signature is found elsewhere in your code.

        Within a function, though, basically means that something gnarly is happening that wouldn’t be obvious, or that the function is doing more than it (probably) should.