From owner-cvs-all Wed Dec 13 13:34:44 2000 From owner-cvs-all@FreeBSD.ORG Wed Dec 13 13:34:37 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id E5EA837B402; Wed, 13 Dec 2000 13:34:33 -0800 (PST) Received: from nas1-171.mea.club-internet.fr (nas1-171.mea.club-internet.fr [195.36.139.171]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA28798; Wed, 13 Dec 2000 22:34:27 +0100 (MET) Date: Wed, 13 Dec 2000 21:34:21 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Mike Smith Cc: "Justin T. Gibbs" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files options src/sys/dev/pci pci_user.c eisa_pci.c pci.c pci_pci.c pcireg.h pcivar.h src/sys/pci pci_compat.c In-Reply-To: <200012132105.eBDL5G309996@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike, I cannot imagine that you missed all the badnesses of changing style of a source without no _strong_ reasons. Here is a sample of them, IMO: - Following the style of a source when modifying it is implicit and expected correctness and politeness, in my opinion. - A real TAB means 1 level of indentation and given a not stupid or not stupidly configured editor, user can select any number of spaces he or she prefers per TAB. - Changing the style of a source is proven to be generally frustrating for the author or current maintainer of that source. - Changing the style produces spurious diffs. - In real life, we have and have had to adapt to mult different programming styles. - Everybody should be able to work happily on 8 spaces per indentation C code, given that this is extremally common. G=E9rard. On Wed, 13 Dec 2000, Mike Smith wrote: > > > - Add prototypes and re-layout the core PCI modules in line with > > > current coding standards (not a major whitespace change, just mov= ing > > > the module data to the top of the file). > >=20 > > Don't you mean, "reformat to my personal code style"? >=20 > Actually, no, I meant that functions should be prototyped, and that the= =20 > module declarations and method tables should be at the top of the file,= =20 > using the prototypes rather than the actual implementations of the=20 > functions. >=20 > However, since I'm in the process of effectively rewriting all of this > code, yes, it's probably going to end up in my own personal variation of > style(9). I started off trying to maintain the original 8-space indents > for new code (which was a mistake, since it now means some substantial > whitespace diffs against work I've already committed), but once it became > clear how much needed to be reworked I decided I might as well do it in a > format I'm comfortable working with. >=20 > > This is not about your style being better than another, but that we > > have a mandated style for a reason. You've shown in the past the abili= ty > > to follow our coding standard, so why are you bucking it now? >=20 > I'm not; I'm just applying the commonsense interpretation of the style=20 > guidelines. If I was just tinkering with a few lines of this code, I'd= =20 > stick with the way it was originally formatted. Since, however, I'm in= =20 > the process of almost entirely rewriting it, and since I expect to be=20 > maintaining it for quite some time to come, it makes a lot of sense to me= =20 > to do it in a style that isn't going to inhibit my work. Incidentally,= =20 > we don't have "a mandated style", we have a set of style guidelines. >=20 > In retrospect, I should probably have waved big red flags at you when you= =20 > mentioned you were working on the cardbus rationalisation, however it=20 > wasn't clear at that point that what I wanted to do with PCI was going to= =20 > necessitate such vigorous change. However one of the objectives of this= =20 > work is to throw away most, if not all of the "cardbus bus" and just=20 > attach PCI to the cardbus bridge. I'm sorry for the inconvenience this= =20 > has inadvertently caused you. >=20 > On the other hand, I'll note that so far all the technical review I've=20 > recived has been criticism of my choice of 4-space indents over tabs. > I find this pretty miserable; the code works just as well (and is just as= =20 > readable) either way. How about focussing on the content? >=20 >=20 > --=20 > .. every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message