Several years ago, I was interviewing for a job. This particular interview was a new experience for me. I had never done pair programming before and was expected to pair program a fairly simple Queue with my interviewer. After the interview, the interviewer was going over my performance and I noticed he docked me for my function names. When I asked what was wrong, they had seemed correct to me. He pointed out that I had named the functions get() and addItem($item), saying that I should be consistent with my function names. Developers using my library seeing addItem($item) would expect getItem($item) or seeing get() would expect add($item). I ended up taking a position at another company, but the interview has always stuck with me. I wouldn't advise anybody to sweat the small stuff. However if there's a 5 minute change that will make the code even marginally more consistent, more readable, more obvious, more predictable, more maintainable, it's worth the time to make the change. When I'm programming, I always try to follow the boy scout rule:

Leave your code better than you found it.

And the same goes for reviewing pull requests, don't ask Does this work?. Instead ask, Can we make this better?. The majority of my co-workers will agree that there hardly exists a pull request I can't find something to comment about. But these small nitpicky changes create an entirely more enjoyable coding experience for future you.