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).
Related
The Effective go has following advice on naming of getters:
Go doesn't provide automatic support for getters and setters. There's
nothing wrong with providing getters and setters yourself, and it's
often appropriate to do so, but it's neither idiomatic nor necessary
to put Get into the getter's name. If you have a field called owner
(lower case, unexported), the getter method should be called Owner
(upper case, exported), not GetOwner. The use of upper-case names for
export provides the hook to discriminate the field from the method. A
setter function, if needed, will likely be called SetOwner. Both names
read well in practice:
Source: https://golang.org/doc/effective_go.html#Getters
Now, this advice doesn't seem to consistent as the stdlib itself violates this multiple times.
As you can see in above screenshot, there are multiple methods which use GetX naming convention which is advised against in the effective go guide.
So the question is is the advice given in guide wrong or these methods are named wrongly & would be fixed in future versions?
These names are not consistent with Go naming by design. Rob Pike, one of the Go creators, says this about the names in the OS package:
There are inconsistencies but this is the key point. It should be Stdout not StdOut, because that name is coming from the underlying system. Similarly it's Fprintf not FPrintf or FPrintF because that is a very familiar name. These names are coming into Go, not being created there, and the initial cap is the admission fee.
The names will not be changed in a future version of Go.
[go-nuts] FunctionName caseinconsistencies
A lot of the all lowercase names were chosen before we had really
figured out what the naming conventions should be. The rule we
adopted, which might be worth revisiting later, was that entry points
in package os or syscall, which are named after equivalents in C, just
had a single capital at the beginning, to avoid needing to decide
where the internal capitalizations are in abbreviations like geteuid
or getwd or chdir. Names like Readdirnames, which are actual words,
might be worth revisiting at some point.
Russ
os: inconsistent casing in names #1187
Is there any sort of rule about the casing of functions used in the
"os" package? Looking through, it doesn't sound like it's very easy
to recall whether a given function should be called LikeThat or
Likethat.
For instance:
Mkdir
MkdirAll
TempDir
Getenv
ForkExec
Readlink
ReadAt
Readdir
It feels very ad-hoc, and hard to recall.
It's a known issue. It's unplanned.
The term "getters" refers to methods on structs that allow you to read values of (often unexported) fields on that struct. The functions you're pointing to are top-level functions which allow you to read values from the OS. That idiomatic rule is not relevant to this case.
I've had a look into CSS setups for a couple of projects that other people developed and I can understand most of what's going on.
The programmers have, however, created some files whose names start with the underscore (for example: _variables.scss). I have seen files named like this in both of the projects.
I can't figure out what this convention represents. Is there a special reason why the people are naming the files this way?
The only reason I can find to use underscore before the name of the partial is what's described in the Sass docs here:
The underscore lets Sass know that the file is only a partial file and that it should not be generated into a CSS file.
Any SASS files not beginning with an underscore will be rendered on their own, which will fail if they are using variables or mixins defined elsewhere.
In the end I have concluded that the underscore is just used to clarify that it is a partial file. We can also use a partial file without using an underscore as prefix.
Sometimes that naming convention is used for templates or template part files, you could find this being used in MVC frameworks.
In other places this might mean that this variable or file is private and can only be accessed by the server or the running program. It all depends on the language you're programming really, but this is simply a naming convention.
It's just a naming convention. When you want to define a name for an interface you define it with (_interface). This is just for compatibility issues, In some cases a program may include classes and interfaces And in order to distinguish between the two, you use _ for interfaces.
This is just one example as you can use it in the BLL layer when working with databases and so on.
It is an emphasis for other developer to notice the variables and objects.
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.
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
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.