Re: Obj-C - your thoughts on hiding data members?
Re: Obj-C - your thoughts on hiding data members?
- Subject: Re: Obj-C - your thoughts on hiding data members?
- From: Dave <email@hidden>
- Date: Wed, 27 Jan 2016 11:35:19 +0000
> 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 (email@hidden)
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:
This email sent to email@hidden