marq | 4a377b8 | 2017-02-16 18:40:19 | [diff] [blame] | 1 | # Chromium Objective-C and Objective-C++ style guide |
| 2 | |
| 3 | _For other languages, please see the [Chromium style guides](https://chromium.googlesource.com/chromium/src/+/master/styleguide/styleguide.md)._ |
| 4 | |
marq | 2647340 | 2017-02-23 15:12:27 | [diff] [blame] | 5 | Chromium follows the |
Mark Cogan | c861304 | 2017-10-18 10:58:49 | [diff] [blame] | 6 | [Google Objective-C style guide](https://github.com/google/styleguide/blob/gh-pages/objcguide.md) |
marq | 2647340 | 2017-02-23 15:12:27 | [diff] [blame] | 7 | unless an exception is listed below. |
marq | 4a377b8 | 2017-02-16 18:40:19 | [diff] [blame] | 8 | |
| 9 | A checkout should give you |
| 10 | [clang-format](https://chromium.googlesource.com/chromium/src/+/master/docs/clang_format.md) |
| 11 | to automatically format Objective-C and Objective-C++ code. By policy, Clang's |
| 12 | formatting of code should always be accepted in code reviews. If Clang's |
| 13 | formatting doesn't follow this style guide, file a bug. |
| 14 | |
| 15 | ## Line length |
| 16 | |
| 17 | For consistency with the 80 character line length used in Chromium C++ code, |
| 18 | Objective-C and Objective-C++ code also has an 80 character line length. |
| 19 | |
| 20 | ## Chromium C++ style |
| 21 | |
Mark Cogan | c861304 | 2017-10-18 10:58:49 | [diff] [blame] | 22 | Where appropriate, the [Chromium C++ style](../c++/c++.md) style guide applies |
| 23 | to Chromium Objective-C and (especially) Objective-C++ |
marq | 4a377b8 | 2017-02-16 18:40:19 | [diff] [blame] | 24 | |
| 25 | ## Code Formatting |
| 26 | |
| 27 | Use `nil` for null pointers to Objective-C objects, and `nullptr` for C++ |
| 28 | objects. |
| 29 | |
| 30 | ## Objective-C++ style matches the language |
| 31 | |
| 32 | Within an Objective-C++ source file, follow the style for the language of the |
| 33 | function or method you're implementing. |
| 34 | |
| 35 | In order to minimize clashes between the differing naming styles when mixing |
| 36 | Cocoa/Objective-C and C++, follow the style of the method being implemented. |
| 37 | |
| 38 | For code in an `@implementation` block, use the Objective-C naming rules. For |
| 39 | code in a method of a C++ class, use the C++ naming rules. |
| 40 | |
| 41 | For C functions and constants defined in a namespace, use C++ style, even if |
| 42 | most of the file is Objective-C. |
| 43 | |
| 44 | `TEST` and `TEST_F` macros expand to C++ methods, so even if a unit test is |
| 45 | mostly testing Objective-C objects and methods, the test should be written using |
| 46 | C++ style. |
| 47 | |
Eugene But | f2df293 | 2018-12-10 23:28:36 | [diff] [blame] | 48 | ## #import and #include in the `ios/` directory |
| 49 | |
| 50 | #import directive can be used to import C++ and Objective-C headers for all |
| 51 | source code in the `ios/` directory. This differs from Google Objective-C Style |
| 52 | Guide, which requires using #include directive for C++ headers. |