From owner-freebsd-current Sat Jan 30 04:41:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA21380 for freebsd-current-outgoing; Sat, 30 Jan 1999 04:41:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA21375 for ; Sat, 30 Jan 1999 04:41:03 -0800 (PST) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.8.8/8.8.7) with ESMTP id HAA23177; Sat, 30 Jan 1999 07:40:40 -0500 (EST) Date: Sat, 30 Jan 1999 07:40:40 -0500 (EST) From: Brian Feldman X-Sender: green@janus.syracuse.net To: Greg Lehey cc: Warner Losh , Julian Elischer , current@FreeBSD.ORG Subject: Re: btokup().. patch to STYLE(9) (fwd) In-Reply-To: <19990130104943.W8473@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 30 Jan 1999, Greg Lehey wrote: > On Friday, 29 January 1999 at 11:02:48 -0700, Warner Losh wrote: > >> If I were working on this code written by someone else it'd leave my > >> editor looking like the top example, that's for sure. I think that > >> "How easy is it to edit a piece of code and still have it do what you > >> expect" is an important consideration, because people DO edit things. > > > > Agreed. > > > >>> I do agree that complex things like: > >>> > >>> if (a | b & c % d ^ e) > >>> > >>> should really have some parents to show what is going on. > >> > >> I have NO idea of what that is doing and I have plans of looking it up in > >> the book to work it out.. > > > > Yes. I agree with that. > > if (a | b & c % d ^ e) > > should have been written as: > > if (((a | (b & (c % d))) ^ e) != 0) > > (then again, either way it is ugly code and should have comments). > > It's interesting that this whole argument has just addressed the > syntax, and nobody has given any consideration to the semantics. In > this example, all variables are a single character. Given the fact > that this expression is probably indented 16 characters, there's a > strong incentive to keep the variable names short, even at the expense > of intelligibility. Consider one possible expansion > > if (((allocationfail | (IGNOREFAILUREMASK & (incount % BLKSIZE))) ^ failures) != 0) > > (yes, this still doesn't make sense, but I can't be bothered to look > for something more appropriate) This is now 99 characters wide, and > it's the kind of code which doesn't gain in legibility by being broken > into multiple lines, especially if the indentation of the follow-on > lines is independent of the structure of the expression. bde has made > it clear he considers code more than 80 characters wide to be Evil. > Question: how many people still limit their editor windows to 80 > characters? I do; doesn't everyone? > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message