Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Christoffer Lerno <email@hidden>
- Date: Wed, 2 Jun 2004 09:28:23 +0800
On Jun 1, 2004, at 21:29, Marcel Weiher wrote:
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.
Err. I was saying that if we didn't have naming conventions like the
ones you mention, we would be using the same for everything and that
would not be a good thing.
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.
Without looking at actual code I make, that is a pretty provokative
claim to make.
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.
I want this caught much earlier than at compile. However you say:
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.
Explain how your "meaningfully named" variables enable you with 100%
accuracy tell local variables from instance vars.
Even stuff like cachedName or temporaryName could potentially be an
instance variable.
You don't know unless you know the method completely, and it is not
obvious at a glance. I want it to be obvious at a glance.
Do you understand?
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:
It was a contrived example that's all. The problem usually, but not
necessarily, manifests itself in longer methods.
MyClass( String newName, InputStream newSource ) {
String upperCaseName = newName.toUpperCase();
source = newSource;
name = upperCaseName;
}
Ok, now look at this:
...
String upperCaseName = newName.toUpperCase();
source = newSource;
name = upperCaseName;
...
In a longer segment of code, could you tell which one is local and
which one is instance var from the three lines above without looking at
the method declaration or the header?
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;
}
An editor like IDEA will automatically catch errors like that without
the need to compile the code.
/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.