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
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

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