I've set Resharper to start everything with in lowercase.
Now, when Visual Studio generates event methodes, like searchButton_Click it warns me that this is not conforming to my naming conventions.
This seems to be because of the underscore in the middle of the sentense. The only other settings with underscores in it are all_lower and ALL_UPPER. But I want just the start of the method or variable to be lowerscore and the rest to use camelCasing.
Is there no setting for this?
I recommend that you don't use that naming convention. Most people will view it as inconsistent. I also recommend that you don't use the default method names. For example, I would have the click method for searchButton simply called Search, or something else appropriate like StartSearch
Related
For instance, for constants, is it:
THIS_CONSTANT
This_Constant
ThisConstant
Or something else...?
In fact, is there any sort of (quasi|)official reference for this whole subject?
I'd also like to be able to quickly double check questions like:
What naming patterns are enforced by Ruby itself (eg, Constants must start with a capital, right?) and which are simply conventions (method_names should be in snake case, right?)?
Are there any conventions for how to write a reminder of what class a variable is supposed to be into its name? ("Hungarian notation" or whatever... I mean, I kinda got the impression that if you ever feel the need to use it in Ruby code, you're Doing It Wrong, but regardless, is there a convention?)
and so on...
The Ruby Style Guide is a public effort to recommend consistent conventions and best practices to Ruby developers. You should check it out.
In brief
The camel case for classes and modules definition we use CamelCase
The snake case for files, variables and methods: snake_case
The syntax highlighting in your text editor can give you some good clues as you're learning a language and trying to develop an instinct for its conventions, enforced and otherwise. I use the Linux Gedit editor.
Yesterday I was pleasantly surprised to find that some of the conventions for commenting recommended by The Ruby Style Guide https://github.com/bbatsov/ruby-style-guide, such as # TODO and # FIXME, show up as bold face bright yellow. Constant names with ALL CAPS are bold cyan. Of course, different editors use different color schemes.
I am tidying up my ancient Cocoa code to use modern naming conventions. There has been lots of discussion on best practices, but I'm unsure of one thing.
I'm thinking about adding a prefix to category method names, to ensure uniqueness. It seem generally agreed that this is a good idea, though most people probably don't bother.
My question is: what about a NSDictionary category method like -copyDeep that does a deep copy? The method used to be named -deepCopy, but I reversed the words as the analyzer looks for a prefix of "copy". Therefore I presumably couldn't add a prefix. And having the "prefix" in the middle or end of the method name seems messy and inconsistent.
I'd also be interested in thoughts on the style of prefix -- I currently use DS (for Dejal Systems) for class prefixes. But I know that Apple now wants to reserve all two-character prefixes for themselves, so am thinking about using Dejal, e.g. my class DSManagedObject would be renamed as DejalManagedObject. And getting back to categories, their methods would be renamed to add a dejal prefix, e.g. from -substringFromString: to -dejalSubstringFromString:. But -dejalCopyDeep would confuse the analyzer, so maybe I'd have to be inconsistent for such methods, and use -copyDeepDejal or -copyDeep_dejal?
I will be re-releasing my categories and various classes as open source once I've cleaned them up, so following the latest conventions will be beneficial.
I emailed the Apple Application Frameworks Evangelist about this, and got a reply that recommended not prefixing category method names. Which conflicts with the advice in the aforelinked WWDC10 session, but I assume reflects Apple's current thinking.
He recommended just looking at the beta seed API diffs to spot conflicts, which is what I've always been doing.
I agree with Kevin Ballard, you should prefix your category method names, particularly if you are going to distribute them to others. But you do have a valid concern the analyzer will be confused by DScopy. The ARC compiler will similarly be confused if the definition/implementation of DScopy is done without ARC and is used by another class using ARC (or vice versa).
My preferred solution is to use "ownership transfer annotations", such as:
NS_RETURNS_NOT_RETAINED
NS_RETURNS_RETAINED
They would be used to override the compilers default behavior of reading method names and acting on them. You might declare DScopy like so: (This declaration must be in a header file that is imported by all the classes that use this method mentioned due to link)
-(DSManagedObject *)DScopy; NS_RETURNS_RETAINED;
Source for NS_RETURNS... WWDC 2011 Session 322 - Objective-C Advancements in Depth. The meat of this issue begins at about time 9:10.
A note about "But I know that Apple now wants to reserve all two-character prefixes for themselves". As a personal preference I like to use the _ character to separate the prefix from the name, it works well for me. You might try something like:
-(DSManagedObject *)ds_copy; NS_RETURNS_RETAINED;
This would give you three characters, and arguably make the method name more readable.
Edit In response to link posted in comment.
However as Justin's answer to your original question says that can be broken.
With regards to attributes; I did not suggest using __attribute__((objc_method_family(copy))) I suggested using NS_RETURNS_RETAINED, which translates to :__attribute__((ns_returns_retained)). While the first example there won't even compile (as he says) using - (NSString *)string __attribute__((objc_method_family(copy))); it compiles with - (NSString *)string; NS_RETURNS_RETAINED; just fine.
Obviously also if the NS_RETURNS_.. are "hidden" from the compiler in separate the .ms or indirected in some other way and the compiler can't see the directives then it won't work. Because of this I would suggest putting the declaration for any methods that may cause the analyzer/compiler confusion in your main .h file (the one that imports all the others) to limit the chances that there will be an issue.
When subclassing a class like MKMapView, is there a preferred way of naming the newly added instance variables? Apple says it reserves the underscore prefix for their own use, so can I just go ahead and use whatever I like without worrying about possible clashes?
You'll want to use a name not used by any of your superclasses — the compiler will error out if you accidentally do and you'll just have to change the variable's name. In general, it's not a very big deal and you can use pretty much whatever you want. It's my observation that category methods are more prone to naming conflict problems than instance variables are.
To be clearer; Apple reserve the underscore prefix for method names not iVars.
Many developers prefer to name their iVars with an underscore prefix to distinguish them from their property names.
There's an entire Apple programming guide dedicated to naming conventions and style in Cocoa.
Since your subclass will tend to have your own prefix (like EHMapView) you may prefix instance variables with _eh_ (e.g. _eh_foo).
I've never understood this, and frankly, it pisses me off to see it in code: variable names that begin with an underscore.
What is the point of this?
I've just installed Resharper 5.1, trying it out and it seems nice, though this one thing is ruining it for me.
I haven't checked, but I'm hoping I can turn it off. But why is it done in the first place?
It's a pretty common style for private fields, some use m_lowerCamelCase, others only _lowerCamelCase and still others lowerCamelCase. For variables inside a functions it's a lot more rare and reshaper by default use lowerCamelCase for them.
Note that the naming section of the design guidelines discourage the use of prefixes for public members but private members are not concerned (And public fields should be used only in really specific cases due to their dangers anyway).
In the reshaper options all of that could be changed in Languages > Common > Naming Style.
You could also save your parameters in the solution or in a file and import/export them. Using that you could set the parameters once and for all for everyone in your team.
Prefixing private instance and/or static members of various kinds with an underscore is a widely-adopted practice ([citation needed], obviously, but it is); this is not the place for me to discuss its rights and wrongs.
In ReSharper | Options you will see Languages | Common | Naming Style (and per-language overrides) that will allow you to instruct ReSharper to do exactly as you wish instead.
It's a common practice to use underscores to denote class variables.
There should be an option in ReSharper to configure what, if anything, you want your class variables to start with. I don't have it installed on this machine so I can't easily check what that option is.
For some reason I never see this done. Is there a reason why not? For instance I like _blah for private variables, and at least in Windows Forms controls are by default private member variables, but I can't remember ever seeing them named that way. In the case that I am creating/storing control objects in local variables within a member function, it is especially useful to have some visual distinction.
This might be counter-intuitive for some, but we use the dreaded Hungarian notation for UI elements.
The logic is simple: for any given data object you may have two or more controls associated with it. For example, you have a control that indicates a birth date on a text box, you will have:
the text box
a label indicating that the text box is for birth dates
a calendar control that will allow you to select a date
For that, I would have lblBirthDate for the label, txtBirthDate for the text box, and calBirthDate for the calendar control.
I am interested in hearing how others do this, however. :)
Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.
I personally prefix private objects with _
Form controls are always prefixed with the type, the only reason I do this is because of intellisense. With large forms it becomes easier to "get a labels value" by just typing lbl and selecting it from the list ^_^ It also follows the logic stated by Jon Limjap.
Although this does go again Microsofts .NET Coding Guidelines, check them out here.
For me, the big win with the naming convention of prepending an underscore to private members has to do with Intellisense. Since underscore precedes any letter in the alphabet, when I do a ctrl-space to bring up Intellisense, there are all of my _privateMembers, right at the top.
Controls, though, are a different story, as far as naming goes. I think that scope is assumed, and prepending a few letters to indicate type (txtMyGroovyTextbox, for example) makes more sense for the same reason; controls are grouped in Intellisense by type.
But at work, it's VB all the way, and we do mPrivateMember. I think the m might stand for module.
I came through VB and have held onto the control type prefix for controls. My private members use lower-camel case (firstLetterLowercase) while public members use Pascal/upper-camel case (FirstLetterUppercase).
If there are too many identifiers/members/locals to have a 90% chance of remembering/guessing what it is called, more abstraction is probably necessary.
I have never been convinced that a storage type prefix is useful and/or necessary. I do, however, make a strong habit of following the style of whatever code I am using.
I don't, but I appreciate your logic. I guess the reason most people don't is that underscores would look kind of ugly in the Properties window at design time. It'd also take up an extra character of horizontal space, which is at a premium in a docked window like that.
Hungarian notation or not, I'm more
curious if people prepend m_ or _ or
whatever they use for standard private
member variables.
Luke,
I use _ prefix for my class library objects. I use Hungarian notation exclusively for the UI, for the reason I stated.
I never use underscores in my variable names. I've found that anything besides alpha (sometimes alphanumeric) characters is excessive unless demanded by the language.
I'm in the Uppercase/Lowercase camp ("title" is private, "Title" is public), mixed with the "hungarian" notation for UI Components (tbTextbox, lblLabel etc.), and I am happy that we do not have Visual Case-Insensitive-Basic developers in the team :-)
I don't like the underscore because it looks kinda ugly, but I have to admit it has an advantage (or a disadvantage, depending on your point): In the debugger, all the private Variables will be on top due to the _ being on top of the alphabet. But then again, I prefer my private/public pair to be together, because that allows for easier debugging of getter/setter logic as you see the private and public property next to each other,
I write down the name of the database column they represent.
I use m_ for member variables, but I'm increasingly becoming tempted to just using lowerCamelCase like I do for method parameters and local variables. Public stuff is in UpperCamelCase.
This seems to be more or less accepted convention across the .NET community.