Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Marcel Weiher <email@hidden>
- Date: Tue, 1 Jun 2004 14:29:54 +0100
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.
Incorrect. And in fact, there are some conventions. For example,
classes are in upper case. Variables in lower case.
"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.
Precisely.
[hating lower case prefixes]
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",
Yes.
but I *have* reaped tangible benefits from adhering to such a naming
scheme. I.e. this has helped me to avoid typos.
And has "helped" you continue with the bad habit of not choosing good
meaningful names. The name clashes were a huge blinking warning light
trying to tell you that you weren't naming your variables
appropriately. The prefixing conventions amount to smashing the
warning light and saying "hey, problem gone". But the problem isn't
gone, you've just smashed the warning light telling you there is a
problem.
private int myvar=4;
public void someMethod()
{
int myvar=3;
return myvar;
}
This will compile and a call will return 3.
So it should. However, gcc will give you a warning for this code.
warning.m:11: warning: local declaration of `myvar' hides instance
variable
If you ignore the warning: tough shit.
[..]
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.
If you name your variables meaningfully, simple typos won't cause these
problems, and you will have readable code.
[awkward, non intention revealing code]
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;
}
Why would I introduce a temp like that? If you (or I) are going to
make boneheaded mistakes, no convention is going to save you (or me)
from that, *per definition*. And again, the problem goes away when you
choose *meaningful* names:
MyClass( String newName, InputStream newSource ) {
String upperCaseName = newName.toUpperCase();
source = newSource;
name = upperCaseName;
}
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.
I can't see how this helps at all, because if you're going to make
silly/stupid mistakes (which I make all the time), your only hope is
the compiler, or the unit tests, because, by definition, you are
already being stupid.
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.
The fact that it is commonly seen does not imply (as you would have us
believe), that this is the only alternative to using prefixing. It is
not. It is a problem, to which prefixing is a wrong solution.
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.
Name your variables appropriately, then this goes away. Name them like
"name" and "inputStream", and you will have the problem. Also, it
seems like your methods may be too long if you are seeing this.
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,
It is not. a / an + Type is used when you don't have a better name,
can't think of one, or are too lazy to come up with one (which can be
perfectly fine). It is not a generic prefixing scheme (though you
might perceive it as such).
this should be "aWeaponMaterial",
Incorrect conclusion based on incorrect assumption. Also, if the type
is XXOre*, then the name should be "anXXOre".
but you are arguing about making any difference between them, so
obviously you don't see a problem.
This sentence no parse.
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.
How about "looking at the code"?
If I give you this variable:
length
Can you guess if that is a local variable, a parameter or an instance
variable?
It is neither. length by itself is just that, a string of characters.
It will only be one of these things inside the code. And inside the
code, it will be pretty obvious which it is, unless the code is badly
written.
I know I can't, so I'd like a way to tell them apart.
I wouldn't. Seriously. If you give me an identifier *out of context*,
I couldn't care less.
Apparently there is some mystical "thinking about names"-skill I'm
missing here.
It is not mystical. However, it is not mechanical either, but does
require thought. Life sucks, doesn't it? ;-)
Maybe that should be incomingObjectArrayLength to compare with
myRecalculatedArrayLength and currentArrayLength, but that still
doesn't REALLY tell me the scope of either.
Why on earth should it have to do that? Also, how does your naming
convention help with two local variables colliding?
int doSomething() {
int myvarl=2;
callSuperDuperMethdod();
int myvarI=3;
return myvarl;
}
Cheers,
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.