• towerful@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      7 months ago

      // increase the dynamically allocated memory space of a word sized integer stored at the memory address represented by the symbol "x" by the integer 1 and terminate the instruction

    • philm@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      Yeah, but unironic…

      If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.

      Good video I really recommend: https://www.youtube.com/watch?v=Bf7vDBBOBUA

      • astraeus@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        7 months ago

        This mindset is good, but unfortunately enforces bad programmers to leave their undocumented code in critical places where someone eventually has to figure out what the hell they were doing or refactor the whole damn thing because they got promoted to middle-management and can’t remember why they even wrote it.

  • EnderMB@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    7 months 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…