Re: C question for you old guys ;-)
Re: C question for you old guys ;-)
- Subject: Re: C question for you old guys ;-)
- From: Jeff Harrell <email@hidden>
- Date: Wed, 11 Jun 2003 10:55:23 -0500
On Wednesday, June 11, 2003, at 10:00 AM, Jay Vaughan wrote:
That nobody else is arguing against "#define is ==" on this list only
means to me that nobody else is arguing against it, not that nobody
shares my opinion...
For the record, I'm gonna come down on the side of saying that "#define
is ==" is not the heinous crime against humanity that you make it out
to be.
Your key point seems to be that confusing between collaborators is bad.
I don't think anybody's going to disagree with that. Any programmer
idiom or design pattern (which is just an idiom writ large, after all)
can be a source of confusion if all involved in its use aren't playing
from the same sheet music. Yes, confusion is bad.
The bigger question is, at what point is the task of bringing new
members of the project up to speed on local coding standards outweighed
by the benefits of adopting those standards?
Personally, I have never had a problem keeping my assignments and
equality comparisons straight. That's just me; I've been lucky. But the
problem is obviously serious enough for others that they seek solutions
to it. I agree that the "value == variable" idiom is a bad one, because
that's just not how English-speakers think about those sorts of
statements. Nobody says "if two is the value of x." People say "if x
has the value 2." That's just how our language is. So "value ==
variable" wouldn't get my vote. But that's an *opinion*, and if I were
working in a group where the consensus of opinion was that it's a good
idea, I'd go along with it.
That's what this is all about: establishing a standard set of idioms
that everybody in a local group can get along with. We're not doing
language design here; it is not necessary for *everybody* to think that
"#define is ==" is a good idea. It's only necessary for the people who
are working on a given set of source files to agree to that.
And before you change the subject to one of "bad names for C vars"
Sorry, but there's no getting around the fact that "is" is a terrible
variable name. If we're talking about making code readable, the first
thing to do is get rid of arbitrary variable names where there's the
possibility of ambiguity. (For myself, I still use i as the index
variable in for loops. "For i equals 0" rolls off my tongue as easily
as "To be or not to be." But everywhere else, variables are words, or
even sentence fragments.)
My point is: do "#define is ==" if you're lazy and like it, but it's a
bad habit
Quite the contrary. The intent is to avoid hard-to-find bugs by
programming with an idiom that makes them impossible (or at least
difficult) to insert. And that is a very GOOD habit. Reasonable people
might disagree about the execution, and it's obvious that they do, but
the intent is exactly right.
Anyway, as you said, this thread is getting 'embarrassing', so lets
just drop it and move along with some nice cocoa, eh?
Oops.
--
email@hidden
http://homepage.mac.com/jharrell
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.