Re: Code Guidelines
Re: Code Guidelines
- Subject: Re: Code Guidelines
- From: Ondra Cada <email@hidden>
- Date: Tue, 1 Jun 2004 13:34:07 +0200
Christoffer,
On 1.6.2004, at 12:19, Christoffer Lerno wrote:
>
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.
Yup, and it is not mystical the slightest bit: it is that (a) there is
no reason altogether to tell parameters from locals: they are the very
very same thing, the only difference being that parameters happen to be
automatically initialized by the actual argument values, (b) if you
keep your code clean and intention-revealing, you hardly ever need to
tell ivars from others, though this might be a bit more arguable.
Myself, I solve (b) by generally using long and very self-explaining
names for ivars (weaponMaterial), whilst using ugly abbreviations for
locals and arguments (wmat). Agreeably a highly arguable technique, but
there's some sense in that: after all, the methods should be kept
short; if a method does not fit into the editor window, so that you
can't see its entire code without scrolling, it's time you refactor
your code. Using an ugly abbrev for just a few lines seems to me all
right; even being old and forgetting, I tend to remember easily what
"wmat" means on line 103, since it was declared on line 99. Anyway, I
use this approach for roughly twenty years, without bumping into a name
collision problem (between ivars/locals), ever.
The *only* case I've ever needed something similar to naming convention
(in other words, where I've sometimes had name collision problems until
I began using suffixes) was in case there are more variables which
contain essentially the same entity, represented for some
implementation-based reason in more different ways, like
int n=123456789;
NSNumber nn=[NSNumber numberWithInt:n];
NSString *ns=[NSString stringWithFormat:@"x",n];
...
Again an arguable, but in my personal experience flawless, technique is
to use suffixes: something like those -n's or -s's above for
locals/parameters, full class names ("weaponMaterialNumber",
"weaponMaterialString") if it ever comes to ivars, which so far
happened just once or twice.
Oh, and incidentally
>
private int myvar=4;
>
public void someMethod()
>
{
>
int myvar=3;
>
return myvar;
>
}
this is quite right, it is exactly how it *should* work. There are
different scopes, and the innermost one should win. Some compiler
warnings may be beneficial, but in principle, the *right* way of things
is this working exactly as suggested by them printouts (which it does
in ObjC, luckily):
static int foo=1;
@interface Foo:NSObject { int foo; } @end
@implementation Foo
static void _foo(void) { printf("should be 1: %d\n",foo); }
static void __foo(int foo) { printf("should be 2: %d\n",foo); }
-init { foo=3; return self; } // not quite correct, allright here
-(void)foo {
printf("should be 3: %d\n",foo);
{
int foo=4; printf("should be 4: %d\n",foo);
{ int foo=5; printf("should be 5: %d\n",foo); }
}
}
@end
int main() {
_foo();
__foo(2);
[[Foo new] foo];
return 0;
}
The scoping is a very desirable and great feature; just use (the
original) FORTRAN or BASIC for awhile if you don't like it ;)
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.