For other languages, please see the Chromium style guides.
Chromium follows the Google Objective-C style guide unless an exception is listed below.
A checkout should give you clang-format to automatically format Objective-C and Objective-C++ code. By policy, Clang’s formatting of code should always be accepted in code reviews. If Clang’s formatting doesn’t follow this style guide, file a bug.
For consistency with the 80 character line length used in Chromium C++ code, Objective-C and Objective-C++ code also has an 80 character line length.
Where appropriate, the Chromium C++ style style guide applies to Chromium Objective-C and (especially) Objective-C++
Use nil
for null pointers to Objective-C objects, and nullptr
for C++
objects.
#pragma mark -
To keep implementation files organized and navigable, method implementations
should be clearly grouped by the interfaces they implement, and each such group
should be marked with a #pragma mark -
, followed by the interface name (see
examples below). This kind of grouping should happen for the implementations’s
public methods, superclass methods, private methods, and each protocol the
implementation conforms to. In each group, methods should appear in the same
order they are defined in the corresponding interface declaration. (This is less
important for superclass methods for UIKit subclasses; it’s not a big deal if
the ordering of UIViewController
subclass methods doesn’t match the UIKit
header).
@interface ExampleViewController : UIViewController<ExampleConsumer,
UITableViewDelegate>
...
@end
@implementation ExampleViewController
- (instancetype)init {
...
}
#pragma mark - Public Properties
- (NSString*)stringProperty {
...
}
... // Other properties
#pragma mark - UIViewController
- (void)viewDidLoad {
...
}
... // Other superclass methods
#pragma mark - UITableViewDelegate
... // Protocol methods
#pragma mark - ExampleConsumer
... // Protocol methods
#pragma mark - Private methods
... // Private methods
Private methods can be grouped differently if it helps make the code more
readable; for example, private methods that are just helpers for methods in
specific protocols could be grouped under a #pragma mark - <Protocol> helpers
,
directly after the protocol methods, instead of with the other private methods.
Remember that any method which isn’t declared in an interface needs a full method comment.
Within an Objective-C++ source file, follow the style for the language of the function or method you’re implementing.
In order to minimize clashes between the differing naming styles when mixing Cocoa/Objective-C and C++, follow the style of the method being implemented.
For code in an @implementation
block, use the Objective-C naming rules. For
code in a method of a C++ class, use the C++ naming rules.
For C functions and constants defined in a namespace, use C++ style, even if most of the file is Objective-C.
TEST
and TEST_F
macros expand to C++ methods, so even if a unit test is
mostly testing Objective-C objects and methods, the test should be written using
C++ style.
ios/
directory#import directive can be used to import C++ and Objective-C headers for all
source code in the ios/
directory. This differs from the Google Objective-C Style
Guide, which requires using #include directive for C++ headers.