> These simplistic examples (creating a URL from a string)
> will work the same no matter how many times you execute them, but a lot of
> real code isn't that simple.
Well *THANK* you, John! ;-) Indeed as I was finishing up that
sermon and packing up my soapbox, I thought of the many shortcomin
IS makes a good point. Moreover, if you have some method which has a
side effect or which might not return the same result every time, "po"
is no good for debugging it. These simplistic examples (creating a URL
from a string) will work the same no matter how many times you execute
them, but a l
> Say what ? Local variables show up perfectly fine in the
debugger. Creating an instance variable just to store intermediate
results is of dubious value.
>
> Even with nested messages, no special magic is needed. To see intermediate
> values, just use the po command.
>
> > po [NSURL URLWi
>1) Write each portion of the code by assigning to intermediate ivars.
>This of course is easiest if you just type them in-line as you write
>them, but then of course they will not show up in the debugger so it
> is better to go ahead and type them in the @interface section.
Say what ? Loca
On Tue, Apr 15, 2008 at 11:44 AM, Johnny Lundy <[EMAIL PROTECTED]> wrote:
> What would be great is if Apple would give us many more convenience methods
> that pared it down to the most common things - like a "- (NSStriing *)
> NSSynchronousURLFetch:(NSString *)theURL" method that just takes a stri
Le 15 avr. 08 à 17:44, Johnny Lundy a écrit :
My Cocoa coding is for hobby only, and only for about 4 years, so I
do not have experience with working in teams or on multi-developer
projects.
But I see this issue in other development environments of recent
issue as well. Apple has provided
-Original Message-
>> 2.) Symmetry can add elegance to the visual aspect of your code, and
>> thus make it more pleasing to the eye, and easier to decipher. For
>> example, when I have a long list of includes, I often do this to
>> them:
>>
>> #include
>> #include
>> #inclu
My Cocoa coding is for hobby only, and only for about 4 years, so I do
not have experience with working in teams or on multi-developer
projects.
But I see this issue in other development environments of recent issue
as well. Apple has provided a rich set of finely-granulated APIs,
which a
Note that not everybody uses monospaced fonts everywhere - this is,
after all, the 21st century. Especially considering that Xcode
allows you to specify that different elements can be different
fonts, styles, etc... For example, I've got my comments to be in a
more readable non-monospac
"Idiot" is fine. ;-)
> I hope that minor, gentle banter of this sort is never considered
> off-topic. It's what glues a community together...
For the record, I think banter is safe, so long as it's accompanied
by relevance. Agreed 100% on the 'community glue' sentiment. Most of
us really *
On Tue, Apr 15, 2008 at 2:09 AM, Adam Leonard <[EMAIL PROTECTED]> wrote:
> Paraphrasing Wil Shipley (I believe), variables are variable. They are
> supposed to change. If you are just creating a temporary variable to use
> only in the next step, it seems unnecessarily wasteful. Your variable names
On Apr 15, 2008, at 9:25 AM, john darnell wrote:
2.) Symmetry can add elegance to the visual aspect of your code, and
thus make it more pleasing to the eye, and easier to decipher. For
example, when I have a long list of includes, I often do this to them:
#include
#include
#include
. It's what glues a community together...
Take care.
John
-Original Message-
From: I. Savant [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 10:20 AM
To: john darnell
Cc: cocoa-dev Developers
Subject: Re: is this badly written code?
> Mr. IS:
*Mister* Idiot Savant
> Mr. IS:
*Mister* Idiot Savant? I like that. ;-)
>My apologies. I have no desire to divert the list to some off-topic
> subject.
I'm not a moderator. Scott (Anguish) may have a different opinion
and his is what counts. It pains me, because I think it is a good
debate but one that will
Mr. LaMarche:
I agree wholeheartedly. Thanks for adding your very salient point.
Mr. IS:
My apologies. I have no desire to divert the list to some off-topic
subject.
R,
John
On Apr 15, 2008, at 10:25 AM, john darnell wrote:
> 4.) Comment verbosely and often. You may understand now
> I'm not going to argue with you because I think you've given some pretty
> good advice here. I'm a fan of white space in my code as well, and though
> there are some stylistic differences between us, I concur with the basic
> concepts you laid out. I just thought a caveat might be in order on #
On Apr 15, 2008, at 10:25 AM, john darnell wrote:
4.) Comment verbosely and often. You may understand now what you are
doing and why, but six months from now, you won't. Don't fool
yourself
by saying "I'll add comments later," because, trust me, later never
comes.
I'm not going to argue
I am a long-time C/C++ programmer, with roots in XBase and Basic. Code
style is a subject that often comes up with newbie programmers
regardless of the language, and it deserves a thoughtful response.
I agree wholeheartedly with Mr. Stiles; more than anything else, your
style of coding *is* a mat
On Apr 14, 2008, at 10:53 PM, Adam Gerson wrote:
In cocoa its very tempting to write a single line of code like:
NSManagedObject *selectedTreeObject = [self delegate]
mainWindowController] treeController] selectedObjects]
objectAtIndex:0];
or to flush it out in to individual lines:
NSWind
Another approach if you are targeting 10.5 is to use the new dot
syntax since the methods you call should be accessors. (Note that this
all assumes that the accessors that use the dot syntax are declared
and defined as returning specific types; i.e., mainWindowController
returns an NSWindow
On Apr 15, 2008, at 4:53 AM, Adam Gerson wrote:
In cocoa its very tempting to write a single line of code like:
NSManagedObject *selectedTreeObject = [self delegate]
mainWindowController] treeController] selectedObjects]
objectAtIndex:0];
If you have to embed a lot of messages, you shoul
On Mon, Apr 14, 2008 at 10:53 PM, Adam Gerson <[EMAIL PROTECTED]> wrote:
> In cocoa its very tempting to write a single line of code like:
> NSManagedObject *selectedTreeObject = [self delegate]
> mainWindowController] treeController] selectedObjects]
> objectAtIndex:0];
>
> or to flush it
Actually, that code isn't smaller, it just replaces "] " with "." in a
couple of places :)
As to whether it does anything special to avoid problems with nil
objects, I have no idea...
Matt Burnett wrote:
Have you thought of using KVC? It makes that code alot smaller, and
(im 99% sure) it deal
Have you thought of using KVC? It makes that code alot smaller, and
(im 99% sure) it deals with things like if treeController returned nil
instead of a NSArray.
NSManagedObject *selectedTreeObject = [self
valueForKeyPath
:@"delegate
.mainWindowController.treeController.selectedObjects.las
I don't think there's anything wrong combining messages into a chain
when you only need one variable from it. With the well-worded method
names common with Cocoa it's not too hard to see what the chain is
doing. Sometimes having a bunch of placeholder variables on each line
can look more
The chained approach is tempting since it's short and convenient, so if
the code is not prone to failure, I'd say go for it.
If you expect that you might need to see intermediate values in the
debugger or there are weird edge cases where something might return nil,
I'd break it out into multip
26 matches
Mail list logo
