Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

[Jean Delvare <jdelvare@suse.de>]

Hi Jani,

On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote:
> On Thu, 22 Sep 2016, Jean Delvare <jdelvare@suse.de> wrote:
> > You need to think in terms of actual use cases. Who uses checkpatch and
> > why? I think there are 3 groups of users:
> > * Beginners. They won't run the script by themselves, instead they will
> >   submit a patch which infringes a lot of coding style rules, and the
> >   maintainer will point them to checkpatch and ask for a resubmission
> >   which makes checkpatch happy. Being beginners, they can only rely on
> >   the script itself to only report things which need to be fixed, by
> >   default.
> > * Experienced developers. Who simply want to make sure they did not
> >   overlook anything before they post their work for review. They have
> >   the knowledge to decide if they want to ignore some of the warnings.
> > * People with too much spare time, looking for anything they could
> >   "contribute" to the kernel. They will use --subjective and piss off
> >   every maintainer they can find.
> >
> > Sadly there's not much we can do about the third category, short of
> > killing option --subjective altogether.
> 
> You could make checkpatch have different defaults for patches and files,
> to encourage better style in new code, but to discourage finding
> problems in existing code.

Fixing old code isn't wrong per se. It's good actually. But only if
done the right way by the right person. I don't think it makes any
sense to use this task as an introduction to kernel development for
newcomers. It doesn't teach them anything about the kernel, really.

-- 
Jean Delvare
SUSE L3 Support