• peopleproblems@lemmy.world
    link
    fedilink
    arrow-up
    63
    arrow-down
    1
    ·
    9 months ago

    I am working with an in-house "rapid development team." They have rigorous intake, story and task break down, scheduling of sprints, QA, definition of done, integration test coverage, E2E and min 90% unit test coverage etc. etc.

    They have a strict policy of "no code comments, self documenting code only." They will go in and remove comments that my DevOps team puts in there, because it screws up that policy.

    Luckily, we adopted the policy of having local branches with these comments in place. Once they move beyond the project, we're putting them in.

    • AA5B@lemmy.world
      link
      fedilink
      arrow-up
      25
      arrow-down
      1
      ·
      edit-2
      9 months ago

      They do have a point though. When we’ve gone through phases where the industry focuses on commenting code and other documentation, most of it is useless.

      Code comments should have a reason, and are no substitute for readable code.

      However you’re also right though that people jump onto “all or nothing”. I recently did a code Review that I held up for comments. In this case, they were doing something very atypical to get around a limitation so it was a clear case of comments needed. The next person through will say “what is this shit?” And “fix” it, without knowing there was a good reason

      • buzziebee@lemmy.world
        cake
        link
        fedilink
        arrow-up
        13
        ·
        edit-2
        9 months ago

        Yeah "why" comments are absolutely fine, "what" comments are useless at best and can be harmful at worst.

        I feel like this constant flood of "write comments" posts are from CS students who are told to comment everything by their lecturers. Descriptive variable and function names help explain the "what" of code pretty well most of the time.

        Sure with some old languages like C89 where you are limited in your variable name length you probably do need comments to explain wtf is going on, but most code bases aren't as constrained.

        • _stranger_@lemmy.world
          link
          fedilink
          arrow-up
          9
          ·
          edit-2
          9 months ago

          I have this argument with other devs all the time.

          Hey, you know this 200 line nested if statement that suddenly returns in the middle of the condition is "7"? Yeah, that needs a refactor or at least a fucking comment.

          I get a pull request that adds a log line that reads something like "special case 7 triggered.".

      • DrQuint@lemm.ee
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        9 months ago

        Having no comments doesn't force code to be self-documenting. I understand the cult of code extremist, but No-Commenters are just WEAK and PATHETIC wannabes trying to immitate the true, functional extremists, such as the 16-Space-Tabbers

    • hoodle@programming.dev
      link
      fedilink
      arrow-up
      12
      ·
      9 months ago

      That's silly. I've never seen comments even as a way to explain what your code is doing (the code often does do that anyway). It's important to say WHY you're doing it the way you are.

      That way anyone else who comes in there can have the same context you did when you implemented it, which imo is where most bugs occur. People don't realize what assumptions you made when it was first written, and then make their own (which can easily clash).

    • Longpork_afficianado@lemmy.nz
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      for i in array_sometimes_we_get_ints_from_upstream_functions_and_need_to_convert_them_to_floats_or_downstream_functions_throw_exceptions: out_array.append(float(i)

    • Aceticon@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      I just love it when people who have no understanding of the purposes, objectives and applicability of various parts of a famous software development process and just follow it in a blind fashion-following way.

      And by "love it" I mean "get frustrated to no end even though by now I should know better".