lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Jul 2007 03:13:46 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	jschopp <jschopp@...tin.ibm.com>
Cc:	Andy Whitcroft <apw@...dowen.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Paul Mundt <lethal@...ux-sh.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.08

On Tue, Jul 24, 2007 at 03:32:59PM -0500, jschopp wrote:
>>> Yep I think the consensus is we need a
>>> "--i-don't-agree-just-check-things-which-will-get-me-rejected-out-of-hand"
>>> option of some sort which will restrict output to the real errors.
>> No, the default should be to show only the real errors.
>
> CodingStyle violations are real errors.
>
> If we have agreed that code should look a certain way, and there is a patch 
> that doesn't look that way, that is an error.  Maybe not a runtime error, 
> but a readability error.  A reviewability error.  A maintainability error.  
> A big waste of everybodies time.
>
> I personally don't care if code is indented with 2 spaces, 4 spaces, or a 
> tab.  What I do care about is that all the code is indented consistently so 
> we don't waste an ounce of our energy reading code/patches and thinking 
> about indentation or even worse spending our time arguing over it on 
> mailing lists when there are better things to argue about.
>
> Back when I wrote the early versions of this script I didn't write it 
> because I'm anal retentive about CodingStyle.  I wrote it for the exact 
> opposite reason.  I was tired of seeing email on mailing lists reviewing 
> patches saying there was indentation with spaces instead of tabs, or 
> trailing whitespace, or { on the wrong line.  It was a waste of the 
> reviewers time, it was a waste of the developers time, it was a waste of 
> the time of everybody on the mailing lists.  We should spend all that 
> energy arguing over the merits of what the code does.

There's a relatively small amount of common codingstyle mistakes 
accounting for most of these mistakes.

> So let's argue over the CodingStyle once and be done with the argument 
> instead of having the argument every day on the mailing lists forever.  We 
> end up with more time to argue over much more interesting subjects and we 
> end up with consistent code that is easy to read, review, and maintain.

It's also important to note that there are slightly different 
codingstyles in different parts of the kernel, and you won't get people 
to agree on one.

A common codingstyle is important, but unifying the last bits is simply 
not worth the hassle.

There are more important things than exploiting the corner cases of 
codingstyle, e.g. could you teach checkpatch.pl to give exactly two 
errors for the following code?


	while (a);
		for (b = 0; b < 50; b++);
			for (c = 0; c < sizeof(struct module); c++)
				d = e;


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ