There are two kinds of NITs. The first kind should really just be linter rules. If it's not important enough to enforce across the project, it isn't worth ment

There are two kinds of NITs. The first kind should really just be linter rules. If it's not important enough to enforce across the project, it isn't worth mentioning now. The second are strongly held opinions the other person doesn't want to make a big deal about. Maybe they are expecting pushback, or not feeling confident in their explanation of the issue. So they couch it in a nit. You should be able to push back on comments you disagree with. Often I'll bring up suggestions that I think would improve the code but that I don't think are must haves. I think we can share a tremendous amount of knowledge in code review. And of course, the easiest way to get fewer code review comments is to thoroughly review your own code with a critical eye. Review it like its someone else's. Find the typos and unclear variables. Anticipate the "nits" that you know are coming.