• Throwaway
    link
    fedilink
    53 months ago

    True, but at the same time its very possible to go too small. A bunch of one line code reviews can really slow progress easily.

    • magic_lobster_party
      link
      fedilink
      53 months ago

      Stuffing multiple tasks into one PR is often bad.

      • It’s harder to review. As a reviewer it’s difficult to know which code change is related to which task.
      • It’s harder to verify. Did you really test every change you made?
      • You might end up with a “hostage” situation. There might be a few code changes in the PR that looks good and is really wanted, but other code changes in the same PR of lower quality. As a reviewer, should you just let these lower quality code changes slide so you can bring in the code change you really want? Probably not, but you’re going to let it slide either way.
      • @[email protected]
        link
        fedilink
        23 months ago

        You might end up with a “hostage” situation.

        Reminds me of a guy I used to work with.

        He’d have like a pretty normal PR to do something like change a field to be read only in some API. But then snuck into the pr there’d also be something like “change application to run locally different than prod for entirely selfish reasons” or “lower global coverage requirements” or “disable type checking in this whole folder”

        • magic_lobster_party
          link
          fedilink
          23 months ago

          I also worked with a guy like that. Impossible to predict what he was going to do in his next PR. Always a nightmare to review. Also exhausting to argue with, so let some things slide because I was so done dealing with his bs.

          • @[email protected]
            link
            fedilink
            23 months ago

            This guy was also difficult to argue with. He was always professional, which I guess is worth something.

            One time he tried to remove all the types from a bunch of code “because they were all going to change later.” I refused to allow this. We went back and forth in the comments for hours. I think eventually the lead or boss got involved. Thankfully people sided with me.

            His “later” project that was allegedly going to change all the things was rejected by the team. The code in question is still used and properly typed a year later.

    • @tatterdemalion
      link
      33 months ago

      Right but it’s pretty rare that a tiny PR actually accomplishes a valuable user story.

      So my point is just that lines of code is mostly irrelevant as long as it’s organized well and does no more than necessary to accomplish the agreed upon goal.