Re: [PATCH] checkpatch: suggest spaces around binary operators instrict mode

[Pavel Roskin]

On 07/08/2011 07:01 PM, Joe Perches wrote:
> On Fri, 2011-07-08 at 17:41 -0400, Pavel Roskin wrote:
> > Signed-off-by: Pavel Roskin<proski@xxxxxxx>
> > ---
> >   scripts/checkpatch.pl |    2 ++
> >   1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index b0aa2c6..9431ada 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -2167,6 +2167,8 @@ sub process {
> >   					if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
> >   						ERROR("need consistent spacing around '$op' $at\n" .
> >   							$hereptr);
> > +					} elsif ($ctx =~ /[^WCE]x[^WCE]/) {
> > +						CHK("spaces suggested around '$op' $at\n" . $hereptr);
>
> Hey Pavel.
>
> This should probably not be an elsif but
> a standalone test.

Maybe.  I just tried to minimize the changes.  I think all of the 
operators in the condition above the lines I changed need spaces around 
them, so I decided to reuse the code block.

Spaces around binary operands are pretty standard.  scripts/Lindent 
would add them.

I understand that not everybody wants that rule enforced, so I used a 
nicely worded warning and enabled it only in the strict mode.  That was 
done to avoid sparking a flamewar about formatting.

There are some cases when missing spaces are palatable, in particular 
with "|", which is thin.  So this may be OK:

(high_id << 8)|(low_id & 0xff)

But I've seen checkpatch ignore stuff like this:

ah->ah_gain.g_current-ah->ah_gain.g_f_corr

And that is just horrible on the eyes.  I want checkpatch to catch that.

> Also, there's an upcoming patch in mm that
> classifies all output ERROR/WARN/CHK types.
>
> This one should be "SPACING".

OK, please keep my suggestion in mind.

--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/