From owner-freebsd-hackers Tue May 28 06:08:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA25526 for hackers-outgoing; Tue, 28 May 1996 06:08:24 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA25498 for ; Tue, 28 May 1996 06:08:21 -0700 (PDT) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id FAA04471 for ; Tue, 28 May 1996 05:07:35 -0700 Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0uONY8-000QYPC; Tue, 28 May 96 14:06 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id NAA23645; Tue, 28 May 1996 13:53:54 +0200 Message-Id: <199605281153.NAA23645@allegro.lemis.de> Subject: Re: Indentation styles To: rnordier@iafrica.com (Robert Nordier) Date: Tue, 28 May 1996 13:53:54 +0200 (MET DST) Cc: hackers@FreeBSD.org (FreeBSD Hackers) In-Reply-To: <199605281137.NAA00234@eac.iafrica.com> from "Robert Nordier" at May 28, 96 01:37:53 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Robert Nordier writes: > > Greg Lehey wrote: >> >> OK, I know source code indentation styles are a hot button, but I >> think I need to press it anyway. >> >> First, a question: is there a recommended FreeBSD indentation style? >> If not, I think there should be. >> >> Now, my problem: I frequently modify other people's code, which >> sometimes causes me problems in reading, simply because the >> indentation varies so much from the indentation that my tools and I >> use. Frequently, I just give up and run the whole source through >> indent(1). The resulting modifications work (usually), but it's >> difficult to pass them back to the original author as diffs. >> >> Therefore, my suggestion: if FreeBSD doesn't have a canonical >> indentation style, it should get one. The style should be >> reproducible with indent(1). (For those of you who don't know, >> indent(1) has a plethora of flags which can create just about any >> indentation style you like). That way, individuals can code in styles >> in which they feel comfortable, but when they submit code, it's in the >> canonical form. It would be an advantage, of course, to choose a >> canonical form which corresponds to the tastes of the majority. >> >> If there is already a recommended FreeBSD indentation style, can it be >> reliably produced with indent(1)? If not, what do people think about >> modifying it to a (closely similar) form which can be created with >> indent(1)? >> >> If there isn't a recommended FreeBSD indentation style, do you agree >> that there should be one? What should it be like? >> >> Finally, a restriction. Indent style can, in some cases, influence >> coding style: for example, if you choose an indent of 8 and indent >> braces 8 characters and the contents of a block another 8 spaces, >> you'll soon run out of margins. Even if you only indent a single 8 >> characters, you'll end up writing different code from people running >> smaller indents. Does this matter? >> >> Thoughts? Flames? > > Yuk! > > I think 'indent' should be hardwired to output to '/usr/tmp'. > > 'indent' is primarily useful as a tool to make sense out of other people's > code. So, if their style differs from yours, indent can be used to > produce a rough translation, which may be useful to promote understanding. > > But 'indent' needs to be used a logical tool, for personal use, not as > something to chop and stretch code into rigid conformance with any > One True Way of doing things. Somehow I think I'm not going to get a majority on my side on this question. > Some people take immense care in the formatting of their code, however > eccentric the layout may appear to those used to a different style. To > stomp all over this with 'indent' would be decidedly a Bad Thing. I don't see any good reason to indent other people's code unless you're going to do serious modifications. If you are, though, as you observe, indent can be a useful tool. In my particular case, I use emacs C mode, and it gets completely confused by hanging braces. I indent differently from the style standards (well, I suppose I could get emacs to change that, but that's only part of the story). I don't have any particular problem with other people going and munging my code after I've done it, I just have serious technical difficulties *producing* this style of code. > Unless you format your code with indent in mind, indent is pretty much > guaranteed to make a mess of it. (Well, of the finer points, anyway.) Well, I think indent has got cleverer. But yes, part of my suggestion is to format your code with indent in mind. > Any particular patch or modification is likely to comprise far less > code than the original source. In these circumstances, it is surely > better to match the style of the original. > > There is an awful lot of code out there, in various indentation styles. > To go in and re-indent the lot of it is going to create massive change, > problems, and uncertainty. (And probably will turn up a few bugs in > indent, which may be detected only when program behavior suddenly > changes.) > > If the required indentation style is applicable only to new code, the > legacy code is always going to be in the majority. So there will not > be the desired overall conformity. > > Indentation styles raise strong feelings. I was looking at some > stuff the other day in which the author specifically prohibits > reformatting the source as part of the conditions for free use and > distribution. (I think it was part of Minix.) Interesting. > I think Greg's concern in valid, but this is one of Nature's > Insoluble Problems. Let's have some sanity, please! Well, we could try. Since I'm really only talking about diffs, it shouldn't be insoluble. Greg