Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Marcel Weiher <email@hidden>
- Date: Tue, 1 Jun 2004 09:41:42 +0100
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.
Yes. For example: the fact that the compiler won't complain.
If it wasn't, we'd all be naming stuff the same way.
Do you have your warnings turned off?
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,
It's not a question of "hate". It is a question of doing something
that isn't useful, and thereby obscuring intent / meaningful naming /
readability of code.
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.
Does Java not provide compiler warnings for that? I thought it did.
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.
Just naming the variable *meaningfully* will do the same. Obscuring
intention by prefixes just makes you think you've done something useful
with naming, and keeps you from coming up with a good name.
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.
Well, we've got the wonderful keyword selectors to help us communicate
intent, and you can give names actual human-readable *names*. For
example: newAccount
accoung = newAccount;
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;
}
This is awkward an non-intention revealing. You are also simply
repeating type information in the name, instead of using the name to
tell us what it is being used for, instead of what it is supposed to
be, which the type already says.
Try this instead:
MyClass( String newName, InputStream newSource ) {
name = newName;
source = newSource;
}
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;
}
Wrong. I don't know why anyone would do it like this, except if you
base it on code that assumes prefixing and then takes the prefixing
away.
[snip: probs with KVC and instance var prefixing]
So, if I can't prefix my instance variables, I should prefix my locals
and my parameters.
No. You should *name* your locals and parameters appropriately.
Apple already does the later, but seemingly not consistent, with the
a/an approach.
As it is not a prefixing scheme, it is not supposed to be "consistent".
However, using that I run into problems with methods that have a
natural expression like this: isMyBlasterWeaponBuildFrom:(XXOre
*)weaponMaterial.
This seems like a very good name, why change it??
Pushing it, I could still go with the a/an expressions though, but
what about local variables?
Just name them appropriately.
I don't really see myself writing loops like this:
for (int theIndex=0;theIndex++;theIndex<10) {}
Well, "i" is the canonical temporary loop index, using anything else
will be confusing. Also, you might try to avoid loops altogether,
where possible.
So I have some problems.
Anyway, my point is: There is a benefit to be gained here
Yes: from good naming. Not from prefixing schemes.
(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.
And that is the big problem. The prefixing makes you *think* that
you've got the naming problem solved, without having to think about
good names. So you end up with really, really awful names made
completely incomprehensible by prefixes stuck to them. Think about
good names instead. It will pay off.
For example, if I would have a instance variable named _name, I could
write code like:
testUniquenessOfName:(NSString *)name
{
... code ...
}
-(BOOL)isNameUnique:(NSString*)candiateName
{
... 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 ...
}
No, you just have to think of a good, intention-revealing name.
[snip 'aName' ]
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.
If you run into collisions, that is your compiler giving you valuable
feedback: you haven't been choosing good, intention-revealing names.
Arbitrarily silencing that feedback sounds like a really, really bad
idea.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.