On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote: > > > > MUST is much stronger language than I would prefer. > > That's what error means, really. When your compiler fails with an > error, you have no choice but to fix your code. Warnings on the other > hand may be ignored sometimes. And they are errors, because of...? > Sure. But I'm afraid you keep changing topics and I have no idea where > you are going. We started with "should there be a space before jump > labels", then out of nowhere we were discussing the wording of the > output of checkpatch (how is that related?) and now you pull statistics > out of your hat, like these numbers imply anything. > > checkpatch was called checkPATCH for a reason. It's main intent was to > prevent NEW (coding-style mostly) errors from creeping into the kernel. > The fact that old code does now always follow these recommendations is > unfortunate but that doesn't make checkpatch wrong or bad. > > ERROR means that the new code isn't allowed to do that. Period. The main intent of checkpatch these days appears to be providing an easy way of thoughtless inflation of commit counts, everything else be damned. Make-work, in other words. The _only_ criterion for adding new checks should be a strong consensus in the core kernel. IOW, it should be descriptive, not prescriptive. "Some people do it this way, some - that" is not a valid reason for "let's make it uniform; that way is just better, so from now on it's a new requirement". Especially when the rationale behind the choice has all the intellectual rigour of feng shui. Some of these checks are common-sense, some are absolutely arbitrary, there are far too many of them and elevating them to the level of compiler errors like you seem to do is rather dishonest. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
