Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD warning

[Joe Perches <joe@perches.com>]

On Fri, 2020-10-23 at 21:06 +0200, Lukas Bulwahn wrote:
> On Fri, 23 Oct 2020, Aditya Srivastava wrote:
> > A quick evaluation on v5.6..v5.8 showed that this fix reduces
> > REPEATED_WORD warnings from 2797 to 907.
> > 
> > A quick manual check found all cases are related to hex output or
> > list command outputs in commit messages.
[] 
> I think this strategy now makes sense and has the right complexity for a 
> good heuristics in this case.

The proper indentation was not followed as described in a previous reply.
This patch also causes conflicts with Dwaipayan's earlier effort.

Lastly, I'm not sure this complexity is worthwhile.

The style is also somewhat complex and doesn't allow for upper and lower
case variants.

I still think that a trivial "is $first hex only" test is simpler.

Perhaps use a hash and an exists test if this is useful at all.

What specific matches were found with this word list?
Why not just add those to the word list?

In all the nearly 1 million commit descriptions in the kernel without
the patch contexts, these were the only hex-like word matches I found
with their count of matches:

76 be
17 Add
13 add
6 dada
2 Bad
2 bad

100 or so false positives in about a million commits isn't many.

dada is not an actual word in a commit message so I suggest
adding hex word like checks only for "be" "add" and "bad".

Maybe "added" too but that hasn't been used as far as I can tell.

But all the other dictionary entries don't appear to be useful.

So maybe something like:

our %allow_repeated_words = (
	add => '',
	added => '',
	bad => '',
	be => '',
);

and

	next if (exists($allow_repeated_words{lc($first)}));