Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Marco Scheurer <email@hidden>
- Date: Tue, 1 Jun 2004 11:47:24 +0200
On Jun 1, 2004, at 3:45 AM, Christoffer Lerno wrote:
[...] 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.
And very bad style IMHO, 'this.' should be mandatory.
[...] 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.
Give local variable names that describe well what they do. For instance
'nameIndex' instead of 'i', 'index', or 'theIndex'. This has two main
advantages: (1) it explains the code and (2) it reduces the risk of
collision. (if you have two variables playing the same rtle, there is
something wrong in your design.) The cost is longer identifier, but
it's worth it.
With this plus the guidelines already described (using 'a'/'an' for
parameters, etc) the only collision problems I sometimes run into is
when I want a local variable to cache the value of an accessor method
(for instance to avoid the cost of sending a message in a loop), in a
class with an ivar of the same name:
- (NSString *) name
{
return name;
}
- (void) doSomething
{
NSString *cachedName = [self name];
while (...) {
do something with cachedName
}
}
Using 'name' for this ivar would be a natural choice, and I'm not too
happy with 'cachedName', 'localName', 'invariantName', ...
[...]
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.
modifiedInSomeWayName is usually well worth the typing effort, theName
doesn't mean anything.
The only other prefix or name I consistently use is 'each' for
enumeration variables. Otherwise I agree with Georg: using 'k' for
constants, 'g' for globals (what about kg or gk for global constants?),
etc. is bad style, a step in the direction of the ultimate programming
style horror: hungarian notation.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.