By definition "nitpicking" is not desirable. The problem is what is the magnitude of improvement that bridges the gap between a nit and a substantive improvemen

By definition "nitpicking" is not desirable. The problem is what is the magnitude of improvement that bridges the gap between a nit and a substantive improvement? When I started off as a code reviewer, I would frequently comment when "I would have done it differently". Now I make sure I only comment when "I would have done it better" and I always explain why it is better. Writing that explanation forces me to ask myself, "is this better?" and I also really want it to be substantially better. There are a category of changes I request which I think of as "nits". Usually these are cosmetic changes that I think genuinely improve the code quality. I think they are worth asking why should we have a misspelling in a documentation string when we could not have it? It's just going to annoy everyone who reads that code until some unrelated change decides to fix it. When I have these kinds of comments, I preface them with "nit:".