Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932175AbZLRQcT (ORCPT ); Fri, 18 Dec 2009 11:32:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932151AbZLRQcP (ORCPT ); Fri, 18 Dec 2009 11:32:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20090 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754975AbZLRQcN (ORCPT ); Fri, 18 Dec 2009 11:32:13 -0500 Date: Fri, 18 Dec 2009 11:32:00 -0500 (EST) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Linus Torvalds cc: Bartlomiej Zolnierkiewicz , =?ISO-8859-15?Q?Am=E9rico_Wang?= , linux-kernel@vger.kernel.org, Alasdair G Kergon , dm-devel@redhat.com Subject: Re: [PATCH] Drop 80-character limit in checkpatch.pl In-Reply-To: Message-ID: References: <200912171618.32882.bzolnier@gmail.com> <200912171708.07899.bzolnier@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2629 Lines: 71 On Thu, 17 Dec 2009, Linus Torvalds wrote: > On Thu, 17 Dec 2009, Bartlomiej Zolnierkiewicz wrote: > > > > Well, it could have been done in the other way: > > > > - ret = sscanf (buf, "0x%lx - 0x%lx", &start_addr, &end_addr); > > + ret = sscanf(buf, "0x%lx - 0x%lx", > > + &start_addr, &end_addr); > > > > Just an example that the limit itself is usually not a problem > > but its literal interpretation is.. > > What? Your version is no better. > > In the above case it doesn't matter, but I've had grep's that fail due to > people splitting the actual string etc, which just drives me wild. We > fixed that to allow checkpatch to skip those warnings, but the fact is, > the fundamnetal problem has always been the "80 character" part. > > I don't think any kernel developers use a vt100 any more. And even if they > do, I bet they curse the "24 lines" more than they curse the occasional > 80+ character lines. > > I'd be ok with changing the warning to 132 characters, which is another > perfectly fine historical limit. Or we can split the difference, and say > "ok, 106 characters is too much". I don't care. But 80 characters is > causing too many idiotic changes. The problem with 106 character --- I have 100-character display on one computer. If the code were be formatted for 106 characters, it would look like bla - bla - bla - bla - bla - bla - bla - bla - bla - bla - bla - bla; --- i.e. every second line wasted. On the other hand, if you go without limit, it will be bla - bla - bla - bla - bla - bla - bla - bla - bla - bla - bla - bla; --- much better. The same problem comes for 132 chatacters --- many people have 128-character display (1024x768 framebuffer) and they see spurious wrapping with 132 character text. In general, if you select "n" as a line width, you find someone with "n - delta" column display who will have problems. It would be best to keep line length is unlimited and say that it is the responsibility of the viewer to wrap it. And make limit of 80 characters only for block comments --- the reader doesn't want to read wrapped words in comments. Mikulas > There are way worse problems in many patches than long lines. Too complex > expressions. Too deep indentation. Pure crap code. People seem to get way > too hung up on ".. but at least it passes checkpatch". > > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/