Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
RE: Style Question (Robert Claeson)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Style Question (Robert Claeson)

> -----Original Message-----
> From: cocoa-dev-bounces+john.darnell=email@hidden
> [mailto:cocoa-dev-bounces+john.darnell=email@hidden]
> Behalf Of Roni Music
> Sent: Saturday, June 28, 2008 1:13 PM
> To: email@hidden
> Subject: Re: Style Question (Robert Claeson)
> the bottom of the page below has one opinion why one style is superior
> the other,
> (at least when it comes to C++ and the way C++ objects behave when
> out
> of scope)

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.


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)

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 >Re: Style Question (Robert Claeson) (From: "Roni Music" <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.