Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Christoffer Lerno <email@hidden>
- Date: Tue, 1 Jun 2004 09:45:34 +0800
On May 31, 2004, at 17:02, Georg Tuparev wrote:
On May 31, 2004, at 1:11 AM, M. Uli Kusterer wrote:
When I feel disciplined, I usually name local variables as
Boys and Girls,
The beauty of Objective-C (inherited from SmallTalk) is that it tries
to treat all kinds of things (objects, classes, protocols,
invocations, ivars, local vars...) in a similar way. With KVC, often
one does not know (and should not know) if there is an ivar, or a pair
of accessor methods. So why so many of you are trying to make the life
complicated? In what way "account" is communicating less useful
information then say "iAccount"? And why the hell so many developers
are happy to write
[accountList lastObject];
but when they add their own NSArray category, they write
[iAccountList mFisrtObject];
Very often I believe all these reverse hungarian notation & friends.
are there to detract the attention from doing the programming to
talking about doing programming. Or are they there to satisfy some
unconscious masochistic and sadistic needs?
just wondering...
(I and my team does what NeXT and later Apple did since 1990 and never
felt the need, or regretted that I or any of my colleagues did not
used [iAccount mBalance] instead of [account balance]...)
I'm gonna drop in at this point to suggest that there is a very real
benefit to differentiating between the names of local vars and instance
vars.
If it wasn't, we'd all be naming stuff the same way. There are already
some guidelines provided here by apple:
Classes: XXSomeClassName
Constants: XXSomeConstantName
Messages: doAction:(XXAction *)anAction withTool:(XXTool *)aTool
Instance variables: someVariableName
These are here so that people won't mix up things. Now you can hate
lower case prefixes like mAccount all you like, but for me coding java
they have already provided a very real benefit: I won't accidently
write a local variable or a parameter that is identical to the name of
an instance variable.
This WILL be caught by the compiler in obj-c, but having errors being
caught by the compiler is slower than having a naming scheme which
prevents this type of errors altogether. My point is, if I have a good
naming scheme there will not be any name-collisions, and this comes out
of the very real situation of such name-collisions happening, just as
Hungarian notation grew out of a need to communicate the actual use of
a pointer. As MFC programmers know, you usually can't just look at they
type of a parameter in MFC and guess what it does. A lot of things are
very non-obvious so enforcing a notation would provide a whole lot more
clues about how to treat the variable.
When I learned Java I saw that there were no need for such a notation,
so I dropped it and introduced prefixed instance variables which gave
you code like this:
MyClass(String name, InputStream inputstream)
{
mName=name;
mInputStream=inputstream;
}
Some people seems to insist to avoid the prefixing in java, but I
consider that a whole lot more error-prone. Their code would look like
this:
MyClass(String name, InputStream inputStream)
{
this.name=name;
this.inputStream=inputstream;
}
You could of course argue that "this." is a sort of prefix, but I
prefer something that is quicker to type and easier for an editor like
IDEA to figure out when using code completion. Besides, this would be
true if people CONSISTENTLY used "this." prefixing instance variables,
but people only do it when there is a risk of collision. Such code is
error-prone and harder to read.
But back to Obj-C... KVC makes prefixing instance variables a bad
thing, so my java naming scheme had to go. I thought I had struck gold
when I saw some code with instance variables prefixed with underscore.
That would have been perfect: the instance variables would be
differentiated without running afoul of KVC. But then I heard these
alarming news about underscore for instance variables being reserved by
apple. I initially thought that only was true for underscore names of
methods (e.g. _myPrivateCallTo:(id)receiver), but it would seem this
extends to instance variables as well.
So, if I can't prefix my instance variables, I should prefix my locals
and my parameters.
Apple already does the later, but seemingly not consistent, with the
a/an approach. However, using that I run into problems with methods
that have a natural expression like this:
isMyBlasterWeaponBuildFrom:(XXOre *)weaponMaterial.
Pushing it, I could still go with the a/an expressions though, but what
about local variables?
I don't really see myself writing loops like this:
for (int theIndex=0;theIndex++;theIndex<10) {}
So I have some problems.
Anyway, my point is: There is a benefit to be gained here (but you have
adhere to the rules or you'll end up harming yourself!), because you
can detect typos etc. quickly. Naming variables etc also become more
straightforward once you have a good standard.
For example, if I would have a instance variable named _name, I could
write code like:
testUniquenessOfName:(NSString *)name
{
... code ...
}
but with "name" taken as an instance variable, I'd have to remember
that and add some crust to the parameter:
testUniquenessOfName:(NSString *)nameValue
{
... code ...
}
Doing the a/an would solve the problem in this case:
testUniquenessOfName:(NSString *)aName
{
... code ...
}
but we also need some naming scheme for local variables:
testUniquenessOfName:(NSString *)aName
{
NSString *theName=[aName someMethodOnNSString]
... code ...
}
or we again run into a situation where we have collisions.
However, the "the" prefix should be consistently used, but that would
be making simple counters and such somewhat of a pain to write. So I
still don't feel the issue is resolved for me.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.