• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Code Guidelines
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Follow-Ups:
    • Re: Code Guidelines
      • From: Christoffer Lerno <email@hidden>
References: 
 >Re: Code Guidelines (From: Christoffer Lerno <email@hidden>)

  • Prev by Date: Re: Code Guidelines
  • Next by Date: Re: Buttons work under 10.3.4 but not 10.2.8
  • Previous by thread: Re: Code Guidelines
  • Next by thread: Re: Code Guidelines
  • Index(es):
    • Date
    • Thread