public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: Andy Whitcroft <apw@canonical.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC V2] checkpatch: flag split arithmetic operations with CHECK
Date: Sun, 10 May 2015 09:52:04 -0700	[thread overview]
Message-ID: <1431276724.29257.20.camel@perches.com> (raw)
In-Reply-To: <1431257186-18013-1-git-send-email-hofrat@osadl.org>

On Sun, 2015-05-10 at 13:26 +0200, Nicholas Mc Guire wrote:
> Simple arithmetic operations should be on one line, if they can be fit,
> rather than splitting at the operator. As this is not in the CodingStyle it
> is limited to --strict use of checkpatch.pl and emits a CHECK only.

The "if they can fit" is an important consideration
not addressed by this patch.

> This extension should flag such lines as CHECK only, as this is not
> mandated by the CodingStyle and in some cases they seem justified 
> (e.g. kernel/sched/fair.c:760 and a few other examples in that file)

> TODO: Move to "# Check operator spacing" section as Joe Perches
>       requested - simply got completely lost in that section...
>       Also not clear if it really is the right place to put it - 
>       spacing issues and split operators are two quite different 
>       problems.
> Question: There are many (518) "lines over 80 char" warnings but that
>           seems to be accepted in checkpatch.pl - should those be 
>           wrapped ?

perl is not c

Regexs are often quite long  so I think trying to
do 80 column wrapping is something that would make
checkpatch even less readable.

> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -2577,6 +2577,58 @@ sub process {
>  			    "Logical continuations should be on the previous line\n" . $hereprev);
>  		}
>  
> +# check for + or - at the end of a line but ignore --/++
> +		if (!($rawline =~ /^\+.*(\+\+|--).*$/) &&
> +		    $rawline =~ /^\+.*(\+|-)$/) {
> +			my $opline = $line; $opline =~ s/^./ /;
> +			my ($curr_values, $types) = annotate_values($opline . "\n", $prev_values);
> +			# its type and the end 'B' -> binary * -> fuss
> +			if($types =~ m/^.*B$/) {
> +			    CHK("ARITHMETIC_CONTINUATIONS",
> +				"Arithmetic expressions should be on one line\n" . $hereprev);

This message is unclear.

Arithmetic should not be on one line as that conflicts
with line length limits.

This test is similar to the logical operator continuation
test at line 2574.

Maybe the message would be clearer with
"Arithmetic operator should be on the previous line\n"

But more globally, maybe this style and message should
be used for many different operators:

o multiplicative	(*, /, %)
o additive		(+, -)
o bitwise shift		(<<, >>)
o relational		(<, >, <=, >=)
o equality		(==, !=)
o bitwise		(&, ^, |)
o logical		(&&, ||)
o assignment		(=, *=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |=)

That's a rather bigger change though and would
be better done with more discussion first.



  reply	other threads:[~2015-05-10 16:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-10 11:26 [PATCH RFC V2] checkpatch: flag split arithmetic operations with CHECK Nicholas Mc Guire
2015-05-10 16:52 ` Joe Perches [this message]
2015-05-10 17:23   ` Nicholas Mc Guire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1431276724.29257.20.camel@perches.com \
    --to=joe@perches.com \
    --cc=apw@canonical.com \
    --cc=hofrat@osadl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox