Re: Style question

[vincent habchi]

Hi again,

first, thanks a lot to all of those who took five minutes of their own time to 
answer my "micro-poll". I really appreciate it.

So, to wrap up, that's mainly up to each person's taste. I think I'll stick to 
the first solution I used since then.

Thanks again!
Vincent

___

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 arch...@mail-archive.com

Re: Style question

[Sean McBride]

On Mon, 30 Aug 2010 08:37:08 -0700, Joar Wingfors said:

>I think that it's definitively preferable to autorelease on the same
>line. It keeps all memory management together, and it's much less likely
>that later rearrangements of the code in question will result in memory
leaks.

And for those that agree, AnalysisTool can flag failure to follow this style:



--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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 arch...@mail-archive.com

Re: Style question

[aglee]

On 30 Aug, 2010,at 11:33 AM, Dave DeLong  wrote:
My personal preference is the latter example. My general rule of thumb is that 
once I -release or -autorelease an object, I shouldn't interact with it 
anymore, since I have relinquished ownership of said object.
 
Definitely true once you release, but the whole purpose of autorelease is to 
allow you to interact with the object despite relinquishing ownership.  For 
example, in Vincent's code he is returning the new autoreleased object 
precisely so the caller can use it.

For all the reasons already given, I actually think this is a case where there is a right 
answer and not so much a matter of personal preference.  If you're going to autorelease, 
do so right away.  I think this falls in the same category as "do the alloc and the 
init in the same statement."

--Andy




The only time I don't follow that guideline is when I'm working inside a method 
that has several different return routes, and cleaning up the appropriate 
objects at each point would just add to the complexity of the method (which 
could be argued is already too complex, but that's for another thread). In this 
case, I'll autorelease the appropriate objects immediately after 
initialization, thereby sparing me from having to clean stuff up in every 
single one of the return conditions.

Dave

On Aug 30, 2010, at 9:29 AM, Vincent Habchi wrote:


Hi everybody,

just an enquiry regarding coding style. What is considered best:

baz = [[[Foo alloc] init] autorelease];
…
return baz;

or

baz = [[Foo alloc] init];
…
return [baz autorelease];

?

Thanks!
Vincent

___

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/aglee%40mac.com

This email sent to ag...@mac.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 arch...@mail-archive.com

Re: Style question

[Joar Wingfors]

On 30 aug 2010, at 08.29, Vincent Habchi wrote:

> baz = [[[Foo alloc] init] autorelease];


I think that it's definitively preferable to autorelease on the same line. It 
keeps all memory management together, and it's much less likely that later 
rearrangements of the code in question will result in memory leaks.

That said, this is a subjective preference, and there are no official 
guidelines on the topic. You'll probably find different opinions if you ask 
around, and you're free to pick any style that you want - as long as you get 
the memory management right in the end.

j o a r


___

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 arch...@mail-archive.com

Re: Style question

[Ken Thomases]

On Aug 30, 2010, at 10:29 AM, Vincent Habchi wrote:

> just an enquiry regarding coding style. What is considered best:
> 
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
> 
> or
> 
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
> 
> ?

As with most style questions, there's no definitive answer.  It's up to you.

Probably, if you know you're going to auto-release the object, it's best to do 
it immediately.  That's safe against early returns, exceptions, reassigning 
'baz' to point to another object, etc.

Regards,
Ken

___

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 arch...@mail-archive.com

Re: Style question

[A.M.]

On Aug 30, 2010, at 11:29 AM, Vincent Habchi wrote:

> Hi everybody,
> 
> just an enquiry regarding coding style. What is considered best:
> 
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
> 
> or
> 
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
> 
> ?

According to the Google Objective-C Style Guide, the former is preferable. The 
rationale for this is pretty solid, too:

http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Prefer_To_autorelease_At_Time_of_Creation#Prefer_To_autorelease_At_Time_of_Creation

Cheers,
M___

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 arch...@mail-archive.com

Re: Style question

[Dave DeLong]

My personal preference is the latter example.  My general rule of thumb is that 
once I -release or -autorelease an object, I shouldn't interact with it 
anymore, since I have relinquished ownership of said object.

The only time I don't follow that guideline is when I'm working inside a method 
that has several different return routes, and cleaning up the appropriate 
objects at each point would just add to the complexity of the method (which 
could be argued is already too complex, but that's for another thread).  In 
this case, I'll autorelease the appropriate objects immediately after 
initialization, thereby sparing me from having to clean stuff up in every 
single one of the return conditions.

Dave

On Aug 30, 2010, at 9:29 AM, Vincent Habchi wrote:

> Hi everybody,
> 
> just an enquiry regarding coding style. What is considered best:
> 
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
> 
> or
> 
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
> 
> ?
> 
> Thanks!
> Vincent


smime.p7s
Description: S/MIME cryptographic signature
___

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 arch...@mail-archive.com

Re: Style question

[F van der Meeren]

Prefer the first

[[[Foo alloc] init] autorelease];

If there is a @throw between the creation and return, there is a chance (if not 
properly handled) that the autorelease won't be called.

On 30 Aug 2010, at 17:29, Vincent Habchi wrote:

> Hi everybody,
> 
> just an enquiry regarding coding style. What is considered best:
> 
> baz = [[[Foo alloc] init] autorelease];
> …
> return baz;
> 
> or
> 
> baz = [[Foo alloc] init];
> …
> return [baz autorelease];
> 
> ?
> 
> Thanks!
> Vincent___
> 
> 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/filip%40code2develop.com
> 
> This email sent to fi...@code2develop.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 arch...@mail-archive.com

Re: Style Question (Robert Claeson)

[Scott Ribe]

> 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)

[Andreas Mayer]

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)

[Scott Ribe]

> 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)

[Gary L. Wade]

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)

[Scott Ribe]

> 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 K&R 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 K&R 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: apology and correction

[Rob Ross]

On Jun 27, 2008, at 10:25 PM, Jens Alfke wrote:



On 27 Jun '08, at 9:45 PM, Rob Ross wrote:

Btw, how many people realize this convention comes from the early  
K&R C book, and the *only* reason they wrote it this way was to  
minimize the number of lines of text their examples would take up  
on each page? It's a type-setting design decision, and has nothing  
to do with how "pure" a programmer you are.


Do you have any citation that shows that was their rationale? From  
the forward of K&R:


"The position of braces is less important, although people hold  
passionate beliefs. We have chosen one of several popular styles.  
Pick a style that suits you, then use it consistently."


Ergo, it was already a popular coding style in 1978. Understandably  
so, as a standard terminal fit even fewer lines (only 24) than did  
a page of print, so minimizing the number of lines was important in  
those days if you wanted to be able to see any amount of your code  
at a time.


—Jens [who learned C in 1980 using K&R 1st ed. and a VT-100]


I stand humbly corrected. I fell victim to reporting something I read  
"on the internet" as fact without checking for sources.


I had seen several people whom I respected mention the theory of the  
book publisher as driving the use of a particular style in the  
original K&R "The C Programming Language" book, and have been  
repeating this as fact. But after your email challenging me to find  
sources, I could not do so after several hours of searching.


So I contacted the sources - both K&R, and to my amazement received  
email replies from both of them. They stated they had never advocated  
for any particular style, and that it was better just to be  
consistent with whatever one chose. And their use of the K&R style  
was well established by Ken Thompson, and something all the members  
of the original Unix and C compiler teams adopted, and still use to  
this day. So the use in the book of the K&R style represented what  
they themselves used on a daily basis.


So please accept my apology for propagating another internet rumor.  
We programmers really need something like snopes.com for programming  
myths :)


Rob Ross, Lead Software Engineer
E! Networks

---
"Beware of he who would deny you access to information, for in his  
heart he dreams himself your master." -- Commissioner Pravin Lal


___

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]

[OT] Re: Style Question

[Steve Byan]

On Jun 28, 2008, at 1:25 AM, Jens Alfke wrote:



On 27 Jun '08, at 9:45 PM, Rob Ross wrote:

Btw, how many people realize this convention comes from the early  
K&R C book, and the *only* reason they wrote it this way was to  
minimize the number of lines of text their examples would take up  
on each page? It's a type-setting design decision, and has nothing  
to do with how "pure" a programmer you are.


Do you have any citation that shows that was their rationale? From  
the forward of K&R:


"The position of braces is less important, although people hold  
passionate beliefs. We have chosen one of several popular styles.  
Pick a style that suits you, then use it consistently."


Ergo, it was already a popular coding style in 1978. Understandably  
so, as a standard terminal fit even fewer lines (only 24) than did  
a page of print, so minimizing the number of lines was important in  
those days if you wanted to be able to see any amount of your code  
at a time.


If you read the source of Unix 6th edition (available in Lion's  
Commentary, ISBN 1-57398-013-7), you will see that they used the "One  
True Brace Style(tm)" :-)


Best regards,
-Steve

--
Steve Byan <[EMAIL PROTECTED]>
Littleton, MA 01460


___

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)

[john darnell]

> -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

[Hamish Allan]

On Sat, Jun 28, 2008 at 6:15 AM, Alex Wait <[EMAIL PROTECTED]> wrote:

> I was meaning to imply that if it was called "FirstName" would setFirstName
> still be called?

See the first word of Jens' reply. But more importantly, just as Jens
says, unask the question :)

Hamish
___

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)

[Roni Music]

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 K&R 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 K&R 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 K&R style.

I personally prefer the K&R 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]

Re: Style Question

[Rob Ross]

On Jun 28, 2008, at 6:39 AM, Sam Mo wrote:


On Jun 28, 2008, at 4:54 AM, Robert Claeson wrote:


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 K&R 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 K&R 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 K&R style.


I got the impression that the latter style was rooted from Pascal  
(or even Algo) programmers where they usually place the "begin" and  
"end" on separate lines.



If you look at an example BCPL program, you'll see the block style is  
similar to the second example above, except the closing curly brace  
is on the same line as the last line of the block - the mirror image  
of the first example


You can d/l the BCPL reference manual that contains an example  
program here:


 http://www.fh-jena.de/~kleine/history/languages/Richards-BCPL- 
ReferenceManual.pdf


(This manual is actually from a TYPEWRITER )

The example starts on page 29. BCPL is using $( and $) as the  
equivalent of { and }


BCPL is the ancestor of B which is the ancestor of C, so this style  
predates C.





___

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

[Sam Mo]

On Jun 28, 2008, at 4:54 AM, Robert Claeson wrote:


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 K&R 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 K&R 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 K&R style.


I got the impression that the latter style was rooted from Pascal (or  
even Algo) programmers where they usually place the "begin" and "end"  
on separate lines.

___

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]

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 K&R 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 K&R 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 K&R style.


I personally prefer the K&R 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]

Re: Style Question

[Jens Alfke]

On 27 Jun '08, at 9:45 PM, Rob Ross wrote:

Btw, how many people realize this convention comes from the early  
K&R C book, and the *only* reason they wrote it this way was to  
minimize the number of lines of text their examples would take up on  
each page? It's a type-setting design decision, and has nothing to  
do with how "pure" a programmer you are.


Do you have any citation that shows that was their rationale? From the  
forward of K&R:


"The position of braces is less important, although people hold  
passionate beliefs. We have chosen one of several popular styles.  
Pick a style that suits you, then use it consistently."


Ergo, it was already a popular coding style in 1978. Understandably  
so, as a standard terminal fit even fewer lines (only 24) than did a  
page of print, so minimizing the number of lines was important in  
those days if you wanted to be able to see any amount of your code at  
a time.


—Jens [who learned C in 1980 using K&R 1st ed. and a 
VT-100]___

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

[Alex Wait]

I was meaning to imply that if it was called "FirstName" would setFirstName
still be called?

I know the convention for naming variables. :)

On Fri, Jun 27, 2008 at 10:13 PM, Jens Alfke <[EMAIL PROTECTED]> wrote:

>
> On 27 Jun '08, at 9:44 PM, Alex Wait wrote:
>
>  if I have a member, let's say a NSString, called FirstName...
>> would the setter still be setFirstName?
>>
>
> Yes. But you shouldn't name the property "FirstName". Property and method
> (and instance variable) names should be lowercased. There are some
> exceptions made when the name begins with an acronym, most commonly "URL",
> that needs to remain uppercase for legibility.
>
> Honestly, no one reading your code is going to care whether you put braces
> at the end of a line or on a new line. But naming conventions are important
> and can help or confuse other people (or yourself, a year later) trying to
> understand it.
>
> —Jens




-- 
If you can't be kind, at least have the decency to be vague.
___

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

[Jens Alfke]

On 27 Jun '08, at 9:44 PM, Alex Wait wrote:


if I have a member, let's say a NSString, called FirstName...
would the setter still be setFirstName?


Yes. But you shouldn't name the property "FirstName". Property and  
method (and instance variable) names should be lowercased. There are  
some exceptions made when the name begins with an acronym, most  
commonly "URL", that needs to remain uppercase for legibility.


Honestly, no one reading your code is going to care whether you put  
braces at the end of a line or on a new line. But naming conventions  
are important and can help or confuse other people (or yourself, a  
year later) trying to understand it.


—Jens___

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

[Shawn Erickson]

On Fri, Jun 27, 2008 at 9:44 PM, Alex Wait <[EMAIL PROTECTED]> wrote:
> I got another Style related question.

/me points at ...

http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/index.html

-Shawn
___

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

[Rob Ross]

I love this one. This becomes a religious issue for some people.

Both styles are popular, you should feel comfortable reading either  
one. Write in the one you like best.


Btw, how many people realize this convention comes from the early K&R  
C book, and the *only* reason they wrote it this way was to minimize  
the number of lines of text their examples would take up on each  
page? It's a type-setting design decision, and has nothing to do with  
how "pure" a programmer you are.


On the tabbing issue, XCode seems to format each line *after* you hit  
return. It usually fixes the line and does the right thing. So type  
your {, hit return, type your next line, hit return, and see if that  
then indents the previous line for you.



Rob Ross, Lead Software Engineer
E! Networks

---
"Beware of he who would deny you access to information, for in his  
heart he dreams himself your master." -- Commissioner Pravin Lal




On Jun 27, 2008, at 9:30 PM, 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.

Is this a Cocoa style? I've seen it on this mailing list and in the
Hillegeass book.

--
If you can't be kind, at least have the decency to be vague.
___

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/rob.ross%40gmail.com

This email sent to [EMAIL PROTECTED]


___

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

[Alex Wait]

I got another Style related question.

if I have a member, let's say a NSString, called FirstName...

would the setter still be setFirstName?

I notice how it capitalizes the first letter even if the member doesn't
start with a capital letter.
if I have a "three word" named variable, let's say firstNameFirst
how would it find it? Or does it do a case insensitive compare?


On Fri, Jun 27, 2008 at 9:40 PM, Shawn Erickson <[EMAIL PROTECTED]> wrote:

> On Fri, Jun 27, 2008 at 9:30 PM, Alex Wait <[EMAIL PROTECTED]> wrote:
>
> > Also since I am using this style, XCode doesn't tab in for me when I type
> {
> > then a return.
>
> It will if you enable it (at least it always does for me).
>
> Use whatever coding style you want however do try to follow Cocoa like
> naming convention.
>
> Personally for methods I have the { on the line following the method
> definition while for all other blocks (most other) I have the { at the
> trailing end of the line (aka end of the if statement line, etc.).
>
> -Shawn
>



-- 
If you can't be kind, at least have the decency to be vague.
___

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

[Shawn Erickson]

On Fri, Jun 27, 2008 at 9:30 PM, Alex Wait <[EMAIL PROTECTED]> wrote:

> Also since I am using this style, XCode doesn't tab in for me when I type {
> then a return.

It will if you enable it (at least it always does for me).

Use whatever coding style you want however do try to follow Cocoa like
naming convention.

Personally for methods I have the { on the line following the method
definition while for all other blocks (most other) I have the { at the
trailing end of the line (aka end of the if statement line, etc.).

-Shawn
___

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]