Re: Style Question (Robert Claeson)
Re: Style Question (Robert Claeson)
- Subject: Re: Style Question (Robert Claeson)
- From: "Gary L. Wade" <email@hidden>
- Date: Fri, 04 Jul 2008 09:16:51 -0700
- Organization: DesiSoft Systems
Scott Ribe wrote:
Anyways, it really is a personal preference. All arguments I've ever seen
that try to claim one style or the other is more correct or safer, are B.S.
(Including the one referenced--the bounds of a block were *ALWAYS*
absolutely vitally important, well before objects & destructors. You sure as
heck don't need to care about destructors in order to care about whether or
not a line of code is within the body of a block!)
The reason I prefer the braces on their own lines vertically in the same
column as the line that defines them:
if (thisTestIsTrue)
{
...
}
else
{
...
}
is that I can easily #if-0 around the if-test and whole else section if
I'm testing out conditional solutions without having to worry about
whether the editor I'm currently using balances my brace set on the
first brace or the second brace. For example, this kind of code just
bugs me when I'm balancing braces back-and-forth:
#if WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue && newFunctionalityIsAvailable) {
#else // WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue) {
#endif // WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
...
}
else
{
...
}
By using my preferred method of brace organization, this is how this
would look:
#if WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue && newFunctionalityIsAvailable)
#else // WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue)
#endif // WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
{
...
}
else
{
...
}
After working on a project in which this method of testing new
functionality was predominant, I changed to this style and never looked
back.
As a matter of
fact, when I take over someone else's code, the first thing I do is
spend the time needed (however much required) to rearrange the position
of the braces to conform with the documented style indicated in the
above references.
Me too, but I think I'm going to quit ;-)
We recently had a guy who liked to do that, but he caused more bugs
(well, he also changed all nils to NULLs, shorts to SInt16s,
short-and-readable if-tests to 2000-character-line '?' operations,
etc.); thankfully, he's no longer with us.
My philosophy is that if you need to change a section of code, it's okay
to change things to your pattern, especially if it adds to readability
or affects issues like I outlined above, but if you don't need to, don't
mess with it. Of course, if you're only talking about a few hundred
lines, maybe I could see that, but when you're talking about thousands
or millions of lines of code (as this guy unnecessarily touched) to go
through, it's probably more trouble than it's worth, and it's an easy
way to anger people when something that had been working perfectly well
is now broken.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden