lkml.org 
[lkml]   [2017]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC patch] checkpatch: Add a test for long function definitions (>200 lines)
On Sat, Dec 16, 2017 at 5:26 PM, Joe Perches <joe@perches.com> wrote:
>>
>> I'm not expecting you to be able to write a perl script that checks
>> the first line, but we have way too many 200-plus line functions in
>> the kernel. I'd like a warning on anything over 200 lines (a factor
>> of 4 over Linus's stated goal).
>
> In response to Matthew's request:
>
> This is a possible checkpatch warning for long
> function definitions.

So I'm not sure a line count makes sense.

Sometimes long functions can be sensible, if they are basically just
one big case-statement or similar.

Looking at one of your examples: futex_requeue() is indeed a long
function, but that's mainly because it has a lot of comments about
exactly what is going on, and while it only has one (fairly small)
case statement, the rest of it is very similar (ie "in this case, do
XYZ").

Another case I looked at - try_to_unmap_one() - had very similar
behavior. It's long, but it's not long for the wrong reasons.

And yes, "copy_process()" is disgusting, and probably _could_ be split
up a bit, but at the same time the bulk of the lines there really is
just the "initialize all the parts of the "struct task_struct".

And other times, I suspect even a 50-line function is way too dense,
just because it's doing crazy things.

So I have a really hard time with some arbitrary line limit. At eh
very least, I think it should ignore comments and whitespace lines.

And yes, some real "complexity analysis" might give a much more sane
limit, but I don't even know what that would be or how it would work.

LInus

\
 
 \ /
  Last update: 2017-12-17 22:47    [W:0.169 / U:2.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site