The thing about nitpicking is that it often addresses only the form without any relation to the problem that the given piece of code is trying to solve (i.e. without any 'meat', as Mat's Mug put it). There are quite a few answers here on CR where people seem to be working off nit lists, answers that only contain hot air about form.
Perhaps there should be a rule strongly discouraging the picking of nits that can be taken care of automatically by a code formatter (prettifier), and that answers purely about form (even if not automatically fixable, e.g. symbol names) are not overly helpful - unless they also demonstrate how the application of their own advice results in a substantially better expression of the algorithm/function.
Also, some people seem to think that even poor/inadequate conventions are better than no conventions at all (e.g. Delphi, Java). The overriding concern should be clear, concise and precise expression of the algorithm or function under consideration. Clean, lean and mean.
The problem is, of course, that only the prettifier criterion is hard (in the sense of 'well-defined') and the rest is about exercising good judgement... Especially as good code is always about the confluence of form and function.
High-quality code often looks deceivingly obvious and slightly boring, belying the hard labour that went into making it so by trimming the fat, removing noise and distilling it to the essential. I.e. people may think 'Obvious, I coulda done that.' which is precisely where many of them are sadly mistaken.