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 matter of personal preference, but allow me to
add my two cents worth here as well, for your consideration.
Too often coders write their code for themselves. After all, they
reason, they are the only ones who will ever touch the module, so what
does it matter how they style their modules? Regrettably, that may not
be true, as I have often found out to my Tylenol-laced regret. And, if
you work on a team of programmers, that most definitely will not be
true. So if there is even a remote possibility that someone else will
have to look at your code someday, write *friendly* code. I personally
would have broken Mr. Gerson's code into several lines and added some
additional padding, but that's just me. Here are some of John's
Arbitrary Rules to Help Readability:
1.) Use LOTS of white space. It's free, and it greatly improves code
readability. The compiler strips out white space when it does its
thing, so adding white space should not affect speed or size of the
final product.
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 <aaa.h>
#include <bbbbbbbbbbbb.h>
#include <cccc.h>
3.) Instead of one massive scroll of code, break it up into small
groups of three or four lines, logically grouped wherever possible. I
am not afraid to do something like this:
int height,
weight,
mass,
visibility,
opacity,
granularity,
density,
xcoord,
ycoord,
volume,
spin,
tilt,
temperature;
If I am feeling particularly obsessive-compulsive on that day, I may
even take the time to alphabetize this list.
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.
5.) If you have a function call or its Objective-C equivalent with
several arguments, spread them out over several lines. Here's an
example using printf (note: what I am trying to illustrate here will not
come across as well if you are not using a non-proportional font):
printf("%s %s %s %s %s,
"This",
"is",
"a",
"printf",
"statement.\n");
There will be some who object to these rules because they take extra
time to implement. Others will complain that writing code in this way
makes it harder to debug, because less code is on the screen. As to the
first objection, I can't argue with it; it does. But the programmer who
takes the time to do so will have code that is so much more readable
that the next programmer in line who is required to maintain it, will
bless him/her, and maybe even put him/her in her will. (grin)
As to the second point, well, all I can say is that the marked
improvement in code readability well offsets the disability of the
screen space it takes, IMHO.
Nevertheless, I will say it again to any who desire to flame me, this is
completely a matter of choice. In the end, write code in the style that
works best for you.
R,
John
-----Original Message-----
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 multiple lines.
This is really a matter of personal preference so YMMV here.
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:
>
> NSWindowController *mainWindow = [[self delegate]
mainWindowController];
> NSTreeController *treeController = [mainWindow treeController];
> NSArray *selectedTreeObjects = [treeController selectedObjects];
> NSManagedObject *selectedTreeObject = [selectedTreeObjects
objectAtIndex:0];
>
> I am looking for some guidance on best practices in a situation with a
> lot of nested calls like this. If ultimately the only value I care
> about is the final one, selectedTreeObject, whats the best way to go
> about getting it? I know "best" is a subjective word. Interested to
> hear all of your opinions.
>
> Adam
_______________________________________________
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]
