Re: C
Re: C
- Subject: Re: C
- From: Jeff <email@hidden>
- Date: Sun, 31 Aug 2003 02:48:37 -0500
On Sunday, August 31, 2003, at 12:31 AM, Clark Cox wrote:
Big fan of the Obfuscated C contest?
Not particularly. :) I tend to like well-commented code whose function
is obvious to any conversant in the language.
If someone conversant in the language has to resort to looking up a
table of operator precedence, then methinks it's not obvious or good
code. It's a judgment call on the part of the programmer. Parentheses
in complicated cases are often better than well-commented code. It can
lessen the need for extraneous comments and allows for easier debugging
and less reading. As Perl programmers know, there's clever programs
that can, with enough effort, be deciphered, and there are well-written
programs that can be easily read and debugged. (Overly clever
programmers are often a pain on team projects.) Besides, in my
experience, less articulate code accompanies less commentary. One thing
I like about the coding idioms of Obj-C is that they encourage more
obviously written code.
When I see extra parentheses, it makes me think "gee, this person
wanted something other than the default behavior". But then, when I
see that they actually wanted the default behavior, it usually makes
me think that they missed something, I then have to scour the calling
code to see if that's what they *really* wanted. If, on the other
hand, the code is written with the language's rules in mind, I know
that parentheses mean "I've changed the order for some reason".
This strikes me as an odd reaction, especially since parentheses are
all part of order precedence, which should simply reinforce its
meaning. Minimal precedence coding seems to be no virtue in and of
itself. To each their own, of course. I tend to come from the school of
thought that comments are to supplement code which could not be made
more clear on its own.
I guess one positive thing to take away from this exchange is that
project teams should at least discuss among themselves their norms for
when and if extra code clarity steps are taken or when it's left to
comment lines (and what the explanation threshold is).
-Jeff
_______________________________________________
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.
| References: | |
| | >Re: C (From: Clark Cox <email@hidden>) |