Re: Style Question (Robert Claeson)
Should be possible, no? Emacs ;-) -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Style Question (Robert Claeson)
Actually, I couldn't agree more with the documentation!
Funny thing is, although I've used the style he advocates for a very long
time (15 years???), I don't agree with his reasoning.
Indentation of *code* should be consistent, an object comes into scope where
it's declared, not at an opening brace, and goes out of scope at the closing
brace, which should be obvious by indentation less than the code it
encloses. In other words, the code - closing brace transition is important,
but not the opening brace - code transition (for statements are arguably an
exception, but even there, I don't think the opening brace position
matters).
Thing is, I remember why I switched all those years ago. It had to do with
narrow lines on terminal screens, and what happens when a line of code is a
tiny bit too long to fit, and the struggle to balance larger indentation
size for scannability against smaller indentation size to avoid running off
the right edge. The style advocated both made pairings easier to see with
narrower indentation, because {} are rather vertical and line up better
visually than some-other-character and }, and because it was highly unlikely
that a { would be hiding just off the right-hand edge of the screen.
Thing is none of those reasons apply with modern tools, and frankly I've
slowly come to prefer KR style. That's right, I use the alternate every day
because of the massive amount of code I have in it, but I find that I
actually prefer to read KR style in an IDE with code folding so on. I
think what it is, is that on a large screen, I prefer not having a nearly
blank line between a block's opening expression (for, while, if...) and its
body. I can see a lot more code at once now, and I prefer that whitespace
breaks it into associated chunks vertically, and on a large monitor, a line
with a single { character might as well be a blank line.
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!)
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 ;-)
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Style Question (Robert Claeson)
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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Style Question (Robert Claeson)
Of course, if you're only talking about a few hundred lines, Oh yes, at most. *NEVER* the size code base you're talking about! -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Style Question (Robert Claeson)
Am 04.07.2008 um 18:16 Uhr schrieb Gary L. Wade:
For example, this kind of code just bugs me when I'm balancing
braces back-and-forth:
Well, I find *this* one preferable:
#if WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue newFunctionalityIsAvailable) {
#else
if (thisTestIsTrue) {
#endif
...
}
else
{
...
}
Removing the redundant comments helps readability a lot more, than
shifting a brace, IMHO. :)
Actually, in my code it'd probably look like this:
#if WE_WANT_TO_ADD_THIS_FEATURE_IN_FINAL_BUILDS
if (thisTestIsTrue newFunctionalityIsAvailable) {
#else
if (thisTestIsTrue) {
#endif
...
} else {
...
}
Because I try to make stand out things that are *important*.
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,
Obviously.
and it's an easy way to anger people when something that had been
working perfectly well is now broken.
Well, just reformatting really shouldn't be able break the build.
Since it's easier for me to read code that is formatted the way *I*
like it, I would be happy if the editor was able to reformat
everything on the fly. That would save me time not only because I
didn't need to reformat by hand but also because it'd speed up my
reading/understanding. Should be possible, no?
Andreas
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
RE: Style Question (Robert Claeson)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roni Music Sent: Saturday, June 28, 2008 1:13 PM To: cocoa-dev@lists.apple.com Subject: Re: Style Question (Robert Claeson) the bottom of the page below has one opinion why one style is superior to the other, (at least when it comes to C++ and the way C++ objects behave when going out of scope) http://www.relisoft.com/book/lang/scopes/2local.html Actually, I couldn't agree more with the documentation! 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. Nevertheless, as I have said in previous posts, the only thing I really insist on with religious fervor is that coders include plenty of whitespace in their code. To me that one choice improves readability far, far more than any placement of braces style that one might argue about. And to forestall a firestorm of objections, let me reinforce the take over part. If I am merely looking at someone else's code or attempting a change when the other party is sick (in emergency situations, and only when pressed by my supervisor), I do my very best to conform to the style they use. Only when I am taking over complete control of the project do I do this. R, John ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Style Question (Robert Claeson)
the bottom of the page below has one opinion why one style is superior to
the other,
(at least when it comes to C++ and the way C++ objects behave when going out
of scope)
http://www.relisoft.com/book/lang/scopes/2local.html
On 28 Jun 2008, at 06:30, Alex Wait wrote:
I have noticed, coming from C++ and Visual Studio (at school), a
couple
style differences
if (value) {
//do something
}
insteasd of
if (value)
{
//do something
}
Also since I am using this style, XCode doesn't tab in for me when I
type {
then a return. This is the style I taught and I would like to
continue the
good habits
during the summer.
I learned C on Unix long before Microsoft had started producing
Windows 1.0. The first style was the first style I learned. I believe
it's called the KR style (from the inventors of C) and it also seems
to be the preferred style in Java if you look in Sun's Java
documentation. When I then learned C++ back in 1988 (from Bjarne
Stroustrup, nonetheless), the KR style was still the style being used.
The first time I came across the latter style was when I had to work
on some Windows C and C++ style. I believe the style was more or less
invented by Microsoft. Most of the Unix/Linux/Cocoa code I've worked
on has used the KR style.
I personally prefer the KR style as it is more compact. I can get a
better sense of the code on a screenful, while a larger portion of the
screen estate is consumed by syntactics (curly braces) that really
doesn't add much of a value in the latter style.
But it's mostly a matter of personal preference. Cocoa doesn't care
and neither does Xcode. You should be able to set up Xcode to indent
properly for you even when using the latter style. If it can't, file a
bug report on bugreporter.apple.com.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
