Karl Wiberg | bb821e2 | 2017-09-03 03:02:12 | [diff] [blame] | 1 | # WebRTC coding style guide |
| 2 | |
| 3 | ## C++ |
| 4 | |
| 5 | WebRTC follows the [Chromium][chr-style] and [Google][goog-style] C++ |
Karl Wiberg | e1ed241 | 2017-09-06 09:10:23 | [diff] [blame^] | 6 | style guides. In cases where they conflict, the Chromium style guide |
| 7 | trumps the Google style guide, and the rules in this file trump them |
| 8 | both. |
Karl Wiberg | bb821e2 | 2017-09-03 03:02:12 | [diff] [blame] | 9 | |
| 10 | [chr-style]: https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md |
| 11 | [goog-style]: https://google.github.io/styleguide/cppguide.html |
| 12 | |
Karl Wiberg | fb4e677 | 2017-09-04 09:27:33 | [diff] [blame] | 13 | Some older parts of the code violate the style guide in various ways. |
| 14 | |
| 15 | * If making small changes to such code, follow the style guide when |
| 16 | it’s reasonable to do so, but in matters of formatting etc., it is |
| 17 | often better to be consistent with the surrounding code. |
| 18 | * If making large changes to such code, consider first cleaning it up |
| 19 | in a separate CL. |
| 20 | |
Karl Wiberg | e1ed241 | 2017-09-06 09:10:23 | [diff] [blame^] | 21 | ### ArrayView |
Karl Wiberg | bb821e2 | 2017-09-03 03:02:12 | [diff] [blame] | 22 | |
Karl Wiberg | e1ed241 | 2017-09-06 09:10:23 | [diff] [blame^] | 23 | When passing an array of values to a function, use `rtc::ArrayView` |
| 24 | whenever possible—that is, whenever you’re not passing ownership of |
| 25 | the array, and don’t allow the callee to change the array size. |
| 26 | |
| 27 | For example, |
| 28 | |
| 29 | instead of | use |
| 30 | ------------------------------------|--------------------- |
| 31 | `const std::vector<T>&` | `ArrayView<const T>` |
| 32 | `const T* ptr, size_t num_elements` | `ArrayView<const T>` |
| 33 | `T* ptr, size_t num_elements` | `ArrayView<T>` |
| 34 | |
| 35 | See [the source](webrtc/api/array_view.h) for more detailed docs. |
Karl Wiberg | fb4e677 | 2017-09-04 09:27:33 | [diff] [blame] | 36 | |
| 37 | ## C |
| 38 | |
| 39 | There’s a substantial chunk of legacy C code in WebRTC, and a lot of |
| 40 | it is old enough that it violates the parts of the C++ style guide |
| 41 | that also applies to C (naming etc.) for the simple reason that it |
| 42 | pre-dates the use of the current C++ style guide for this code base. |
| 43 | |
| 44 | * If making small changes to C code, mimic the style of the |
| 45 | surrounding code. |
| 46 | * If making large changes to C code, consider converting the whole |
| 47 | thing to C++ first. |
Karl Wiberg | ee3d760 | 2017-09-04 12:46:47 | [diff] [blame] | 48 | |
| 49 | ## Build files |
| 50 | |
| 51 | ### Conditional compilation with the C preprocessor |
| 52 | |
| 53 | Avoid using the C preprocessor to conditionally enable or disable |
| 54 | pieces of code. But if you can’t avoid it, introduce a gn variable, |
| 55 | and then set a preprocessor constant to either 0 or 1 in the build |
| 56 | targets that need it: |
| 57 | |
| 58 | ``` |
| 59 | if (apm_debug_dump) { |
| 60 | defines = [ "WEBRTC_APM_DEBUG_DUMP=1" ] |
| 61 | } else { |
| 62 | defines = [ "WEBRTC_APM_DEBUG_DUMP=0" ] |
| 63 | } |
| 64 | ``` |
| 65 | |
| 66 | In the C, C++, or Objective-C files, use `#if` when testing the flag, |
| 67 | not `#ifdef` or `#if defined()`: |
| 68 | |
| 69 | ``` |
| 70 | #if WEBRTC_APM_DEBUG_DUMP |
| 71 | // One way. |
| 72 | #else |
| 73 | // Or another. |
| 74 | #endif |
| 75 | ``` |
| 76 | |
| 77 | When combined with the `-Wundef` compiler option, this produces |
| 78 | compile time warnings if preprocessor symbols are misspelled, or used |
| 79 | without corresponding build rules to set them. |