Code Naming Basics
An often overlooked aspect of the design of object-oriented software libraries is the naming of classes, methods, functions, constants, and the other elements of a programmatic interface. This section discusses several of the naming conventions common to most items of a Cocoa interface.
General Principles
1.Clarity
It is good to be both clear and brief as possible, but clarity shouldn’t suffer because of brevity:
In general, don’t abbreviate names of things. Spell them out, even if they’re long:
- You may think an abbreviation is well-known, but it might not be, especially if the developer encountering your method or function name has a different cultural and linguistic background.
- However, a handful of abbreviations are truly common and have a long history of use. You can continue to use them; see “Acceptable Abbreviations and Acronyms.”
- Avoid ambiguity in API names, such as method names that could be interpreted in more than one way.
Consistency - Try to use names consistently throughout the Cocoa programmatic interfaces. If you are unsure, browse the current header files or reference documentation for precedents.
- Consistency is especially important when you have a class whose methods should take advantage of polymorphism. Methods that do the same thing in different classes should have the same name.
No Self Reference - Names shouldn’t be self-referential.
Constants that are masks (and thus can be combined in bitwise operations) are an exception to this rule, as are constants for notification names.
For More Details Please Click here :Apple Docs
No comments:
Post a Comment