lkml.org 
[lkml]   [2016]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: "CodingStyle: Clarify and complete chapter 7" in docs-next
    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.

    \
     
     \ /
      Last update: 2016-09-23 00:02    [W:3.226 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site