Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Christoffer Lerno <email@hidden>
- Date: Tue, 1 Jun 2004 18:19:06 +0800
On Jun 1, 2004, at 16:41, Marcel Weiher wrote:
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?
No. Obviously you did not understand I was referring to having naming
conventions for all sorts of things, including methods and constants.
"Naming stuff the same way" = naming all things in a similar manner.
For example I could use the XXSomeName-scheme for everything including
instance variables. This would not be a good thing.
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.
Look, you say "this is so", but I *have* reaped tangible benefits from
adhering to such a naming scheme. I.e. this has helped me to avoid
typos.
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.
private int myvar=4;
public void someMethod()
{
int myvar=3;
return myvar;
}
This will compile and a call will return 3.
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 to catch typos or similar mistakes before you compile.
Catching errors at compile-time is much slower than catching them
straight away.
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;
}
And now try this:
MyClass( String newName, InputStream newSource ) {
String name = newName.toUpperCase();
source = newSource;
// this could be correct code, missing a line:
// this.name=name;
}
With a prefix this:
MyClass( String newName, InputStream newSource ) {
String mName = newName.toUpperCase(); // this is always a typo
source = newSource;
}
Will always be an error, since mName is reserved for private/protected
variables. One typo is ambigous, the other isn't. It is true that obj-c
does not allow code like the above, but waiting until compile-time to
spot it is not so good.
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.
No, this is commonly seen.
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.
If I have a method doing some amount of work and I need to introduce
temporary local variables, then there IS the risk of name collision.
It's not a theoretical thing, it's happening to me already.
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??
If a/an is solving the name-collision problem, this should be
"aWeaponMaterial", but you are arguing about making any difference
between them, so obviously you don't see a problem.
(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.
I am not advocating hungarian notation for java, and I'm not advocating
my prefixing scheme for obj-c. BUT I do need a way to tell
locals/parameters from instance variables.
If I give you this variable:
length
Can you guess if that is a local variable, a parameter or an instance
variable? I know I can't, so I'd like a way to tell them apart.
Apparently there is some mystical "thinking about names"-skill I'm
missing here.
Maybe that should be incomingObjectArrayLength to compare with
myRecalculatedArrayLength and currentArrayLength, but that still
doesn't REALLY tell me the scope of either.
/C
_______________________________________________
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.