> I'd suggest it's not necessary. What I like about member naming conventions > has to do with identifying their scope. In my personal programming style, I > name things with a single lower-case letter to make their scope known; that > makes it much easier to track down a variable and understand its use (more > useful than type, which is generally obvious and not actually the important > in context, and which can change over time). I'd suggest that accessibility > of a symbol is not all that important when looking at the code, either. > > FWIW, my convention comes from PowerPlant days (and hence, C++): > > • Local variables start with a lower-case letter. Local variables are > declared as close the point of first use as possible. > • Parameters start with "in", "out", or "inout", depending on their intended > use. > • Member variables (ivars) start with a lower-case "m" (rather than an > underscore). Their corresponding property names delete the prefix character > and start with a lower-case letter. > • Static member variables (which don't really exist in Obj-C, but which I > implement as file-scope variables) are prefixed with "s". > • Constant variables, either via "const" keyword or #define, are camel-case > and prefixed with "k" > • Preprocessor flag are camel-case and prefixed with "q". > • Preprocessor macros are treated like free functions (camel-case), and > implemented as inline functions whenever possible. > > Knowing the *scope* of a variable in unfamiliar or long-forgotten code, I > find, helps me understand what's going on more than any other piece of > information.
Definitely, 100% agree, also once you have implemented a fair amount of code in a project that follow your conventions, you find Programming Patterns begin to emerge and common pieces of code stand out and make refactoring much easier. Cheers Dave _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
