I know that constants start with the k
prefix, but does anyone have their own constant prefix, so they can easily get completion on their constants, instead of Apple's?
I use a three letter prefix for my classes because of my company name, let's pretend it's OMG
. I tried prefixing my constants with omgkConstantName
but that isn't very satisfying. I was also toying with either kk
or ok
(the o is from the OMG.) Or maybe I should do kOMGConstantName, that seems more Cocoa-ish?
It seems really useful to quickly get to your own constants, the same way you might want to get to your own classes. Does anyone do this? Is it terrible Cocoa style?
Also, is there a good naming convention for static variables you would only use in one class, like keys for a JSON dictionary? Should they have the k
? Should they start uppercase, or do they follow normal case conventions?
// Static Variables
static NSString *searchTextKey = @"searchText";
static NSString *searchResultsKey = @"searchResults";
(more)
The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)
Static variables can be accessed by calling with the class name ClassName. VariableName. When declaring class variables as public static final, then variable names (constants) are all in upper case. If the static variables are not public and final, the naming syntax is the same as instance and local variables.
Constants should be written in uppercase characters separated by underscores. Constant names may also contain digits if appropriate, but not as the first character.
I try to consistently use kJAFoo
(or kXXFoo
where XX is a project prefix) for my public constants – especially actual const
s which are exported symbols – but generally use kFoo
for enums or static const
s inside an implementation file. Similarly, I use sFoo
for static variables and gJAFoo
in the rare cases where I use exported globals.
None of these cases are as important as namespacing classes (and methods in categories on imported classes), though, since most types of conflicts will emerge at compile or link time rather than runtime.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With