Naming rules are important for easily maintainable code. Objective-c's method names are often very long, but blocks of code read like prose, and do not require too much code comments.
When writing pure Objective-c code, we basically adhere to the standard objective-c naming rules, which may be quite different from the C + + style guide. For example, Google's C + + style Guide recommends using underscore-delimited words as variable names, while the (Apple) style Guide uses the Hump nomenclature, which is common in the objective-c community.
All classes, categories, methods, and names of variables use all-uppercase acronyms. This follows Apple's standard nomenclature, such as URLs, TIFF, and EXIF.
When writing objective-c++ code, things are not so simple. Many projects need to implement cross-platform C + + APIs and mix some objective-c, Cocoa code, or direct C + + as the backend, with native Cocoa code for the front end. This leads to the direct disunity of the two naming methods.
Our solution is that the coding style depends on which language the method/function is implemented in. If you are in a@implementationstatement, use the objective-c style. If you implement a C + + class, you use the C + + style. This avoids a function inside the instance variable and local variable naming rules confusion, seriously affects the readability.
Filename
Tip
The file name should reflect what class it implements-including case. Follow the conventions of the project you are participating in.
The file should have the following extension:
. h |
C/c++/objective-c's header file |
. m |
OJBECTIVE-C implementation file |
, m/ |
ojbective-c++ implementation file |
. cc |
Implementation files for pure C + + |
. C |
Implementation file for pure C |
The file name of the category should contain the extended class name, such as:gtmnsstring+utils.hor ' gtmnstextview+autocomplete.h '.
Objective-c++
Tip
Within the source code file, the ojbective-c++ code follows the style of the function/method you are implementing.
To minimize the clash of naming styles between cocoa/objective-c and C + +, choose the coding style based on the function/method to be implemented. When implementing a@implementationstatement block, use the OBJECTIVE-C naming convention, or C + + naming conventions If you implement a C + + class.
// file: cross_platform_header.h
class CrossPlatformAPI {
public:
...
int DoSomethingPlatformSpecific(); // impl on each platform
private:
int an_instance_var_;
};
// file: mac_implementation.mm
#include "cross_platform_header.h"
// A typical Objective-C class, using Objective-C naming.
@interface MyDelegate : NSObject {
@private
int instanceVar_;
CrossPlatformAPI* backEndObject_;
}
- (void)respondToSomething:(id)something;
@end
@implementation MyDelegate
- (void)respondToSomething:(id)something {
// bridge from Cocoa through our C++ backend
instanceVar_ = backEndObject->DoSomethingPlatformSpecific();
NSString* tempString = [NSString stringWithInt:instanceVar_];
NSLog(@"%@", tempString);
}
@end
// The platform-specific implementation of the C++ class, using
// C++ naming.
int CrossPlatformAPI::DoSomethingPlatformSpecific() {
NSString* temp_string = [NSString stringWithInt:an_instance_var_];
NSLog(@"%@", temp_string);
return [temp_string intValue];
}
Class name
Tip
The class name (and the category, protocol name) should be capitalized, and the word will be split in hump format.
The application layer code should try to avoid unnecessary prefixes. Adding the same prefix to each class is not helpful for readability. When you write code that expects to be reused between different applications, you should use a prefix (for example:gtmsendmessage).
Class aliases
Tip
The category name should have a two or three-letter prefix to indicate that the category is part of the project or that the category is generic. The category name should contain the name of the class to which it is extended.
For example, to create a category for parsing based onNSString, we will place the category in a file namedgtmnsstring+parsing.h. The category itself is namedgtmstringparsingadditions(yes, we know that the class name differs from the file name, but there may be several different parsing related categories in this file). The methods in the category should be prefixed withgtm_mycategorymethodonastring:to avoid naming conflicts, because Objective-c has only one namespace. If the code is not shared and is not run in a different address space, the method name is less important.
The class name and the parentheses that contain the category name should be separated by a space.
Objective-c Method Name
Tip
The method name should start with a lowercase letter and mix the hump format. Each named parameter should also start with a lowercase letter.
The method name should be read as if it were a sentence, which means that you should choose the name of the parameter that you want to read together with the method name. (for example,convertpoint:fromrect:orreplacecharactersinrange:withstring:). See Apple's Guide to naming Methods for details.
Accessor methods should be the same as the names of the member variables theywant to get, but should not be prefixed with get. For example:
(ID)getdelegate//AVOID(ID)delegate//Good
This is limited to the method name of Objective-c. The naming rules for C + + methods and functions should follow the rules in the C + + style guide.
Variable name
Tip
The variable name should start with a lowercase letter and use the hump format. The member variable of the class should be underlined as a suffix. For example:mylocalvariable,myinstancevariable_. If you cannot use the@propertyof OBJECTIVE-C 2.0, member variables that use KVO/KVC bindings can be prefixed with an underscore.
Common variable Name
For static properties (intor pointer), do not use Hungarian nomenclature. Try to make a descriptive name for the variable. Don't worry about wasting column widths, because it's more important for new code readers to immediately understand your code. For example:
-
-
wrong naming:
int w;
int nerr;
int nCompConns;
tix = [[NSMutableArray alloc] init];
obj = [someObject object];
p = [network port];
-
-
The correct naming:
int numErrors;
int numCompletedConnections;
tickets = [[NSMutableArray alloc] init];
userInfo = [someObject object];
port = [network port];
Instance variable
Instance variables should be mixed-case and underlined as suffixes, such asusernametextfield_. However, if you cannot use OBJECTIVE-C 2.0 (the limitation of the operating system version) and you use the KVO/KVC bound member variable, we allow the exception (translator Note:kvo=key Value Observing,kvc=key Value Coding )。 In this case, you can prefix the name of the member variable with an underscore, which is the key/value naming convention that Apple accepts. If you can use Objective-c 2.0,@propertyand@synthesizeprovide solutions that follow this naming convention.
Constant
Constant names (such as macro definitions, enumerations, static local variables, and so on) should start with the lowercase letterK, separating the words using the hump format, such as:kinvalidhandle,kwriteperm.
Google objective-c Coding style (2) naming