27
While reviewing a PR, you find some piece of code that seems to work perfectly well, but some functions are written in a style that you don't particularly favor. What do you do? (cupid.careers)
submitted 2 years ago by to c/experienced_devs@programming.dev
16 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 13 points 2 years ago (5 children)

Not enough information.

New team member? Show them the style guide and where it doesn't match.

Is the style guidelines consistently followed elsewhere? If not, I'd just approve it.

Do I have a good relationship with the other developer, and can they handle criticism? If not, I probably would not want to be the one reviewing it, but if I did I would likely let it go and fix it later. Fight more important battles.

Otherwise, how important is that piece of code? I'd immediately approve a one-off script, but if it's an core piece of code, I assume the dev missed it and point it out. Happens to everyone.

etc. etc.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] [S] 10 points 2 years ago (4 children)

    I had to shorten the title, but some of the information you say is missing is actually covered on the question.

    Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like "Whatever style decision is important should be covered in the style guide. If you don't have a style guide, then I'd assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I'd rather spend time working on new features and shipping than arguing over style preferences."

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    Your answer doesn't give confidence that you care about how the code looks. Could imply that you're sloppy. Some people are very opiniated about style and think it matters a lot. They would be unhappy with people who say it doesn't really matter.

    They'd likely welcome fixes or comments on style. Other people would be very angry if you held up their PR with such trivialities.

    I had strong style preferences when I was younger, but after working on so many projects with different styles I really don't care anymore about any particular style. I just make sure to seamlessly match the style of the code around it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 2 years ago

    I work with Python. Usage of formatting tools (black, ruff) are widely adopted. Part of its Zen is "there should be one way to do it", most of its idioms are widely adopted and if you ask anyone about an example of a PEP, they will respond with "8".

    That is to say, "how python code should look" is somewhat of a solved problem. Any occasional differences that might show up in a codebase are likely to be minor that are simply not worth arguing for.

    I think that the interviewer was mostly looking for an answer where I could talk about how I deal with conflict. But to be honest if that was the case I would be either more straightforward about the question, or I would try a different scenario with something that might happen more frequently.

  • permalink
  • fedilink
  • source
  • parent