admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Review style guide for freshness

Browse Source 
No-Try: True
Bug: b/374699518
Change-Id: I9060b03b29574f7a6e330a9bc185636210df0a9a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366201
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43276}
This commit is contained in:
Danil Chapovalov 2024-10-22 13:18:14 +02:00 committed by WebRTC LUCI CQ
parent 29a4ada168
commit d42640c75d
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
g3doc/style-guide.md
View File

@ -1,5 +1,5 @@
<!-- go/cmark --> <!-- go/cmark -->
<!--* freshness: {owner: 'danilchap' reviewed: '2024-04-17'} *--> <!--* freshness: {owner: 'danilchap' reviewed: '2024-10-22'} *-->
# WebRTC coding style guide # WebRTC coding style guide
@ -166,7 +166,7 @@ Prefer `webrtc::CallbackList`, and manage thread safety yourself.
The following smart pointer types are recommended: The following smart pointer types are recommended:
* `std::unique_ptr` for all singly-owned objects * `std::unique_ptr` for all singly-owned objects
* `rtc::scoped_refptr` for all objects with shared ownership * `webrtc::scoped_refptr` for all objects with shared ownership
Use of `std::shared_ptr` is *not permitted*. It is banned in the Chromium style Use of `std::shared_ptr` is *not permitted*. It is banned in the Chromium style
guide (overriding the Google style guide). See the guide (overriding the Google style guide). See the
@ -176,7 +176,7 @@ information.
In most cases, one will want to explicitly control lifetimes, and therefore use In most cases, one will want to explicitly control lifetimes, and therefore use
`std::unique_ptr`, but in some cases, for instance where references have to `std::unique_ptr`, but in some cases, for instance where references have to
exist both from the API users and internally, with no way to invalidate pointers exist both from the API users and internally, with no way to invalidate pointers
held by the API user, `rtc::scoped_refptr` can be appropriate. held by the API user, `scoped_refptr` can be appropriate.
[chr-std-shared-ptr]: https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#shared-pointers-banned [chr-std-shared-ptr]: https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#shared-pointers-banned
@ -192,7 +192,8 @@ already familiar to modern C++ programmers. See [Avoid std::bind][totw-108] for
`std::function` is allowed, but remember that it's not the right tool for every `std::function` is allowed, but remember that it's not the right tool for every
occasion. Prefer to use interfaces when that makes sense, and consider occasion. Prefer to use interfaces when that makes sense, and consider
`rtc::FunctionView` for cases where the callee will not save the function `rtc::FunctionView` for cases where the callee will not save the function
object. object. Prefer `absl::AnyInvocable` over `std::function` when you can accomplish
the task by moving the callable instead of copying it.
### Forward declarations ### Forward declarations