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?
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
