Date: Wed, 13 Dec 2000 21:34:21 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mike Smith <msmith@FreeBSD.org> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, 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 Message-ID: <Pine.LNX.4.10.10012132115150.1407-100000@linux.local> In-Reply-To: <200012132105.eBDL5G309996@mass.osd.bsdi.com>
index | next in thread | previous in thread | raw e-mail
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érard. 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 moving > > > the module data to the top of the file). > > > > Don't you mean, "reformat to my personal code style"? > > Actually, no, I meant that functions should be prototyped, and that the > module declarations and method tables should be at the top of the file, > using the prototypes rather than the actual implementations of the > functions. > > 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. > > > 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 ability > > to follow our coding standard, so why are you bucking it now? > > I'm not; I'm just applying the commonsense interpretation of the style > guidelines. If I was just tinkering with a few lines of this code, I'd > stick with the way it was originally formatted. Since, however, I'm in > the process of almost entirely rewriting it, and since I expect to be > maintaining it for quite some time to come, it makes a lot of sense to me > to do it in a style that isn't going to inhibit my work. Incidentally, > we don't have "a mandated style", we have a set of style guidelines. > > In retrospect, I should probably have waved big red flags at you when you > mentioned you were working on the cardbus rationalisation, however it > wasn't clear at that point that what I wanted to do with PCI was going to > necessitate such vigorous change. However one of the objectives of this > work is to throw away most, if not all of the "cardbus bus" and just > attach PCI to the cardbus bridge. I'm sorry for the inconvenience this > has inadvertently caused you. > > On the other hand, I'll note that so far all the technical review I've > 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 > readable) either way. How about focussing on the content? > > > -- > .. 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 messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10012132115150.1407-100000>