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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10012132115150.1407-100000>