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 -->
<!--* freshness: {owner: 'danilchap' reviewed: '2024-04-17'} *-->
<!--* freshness: {owner: 'danilchap' reviewed: '2024-10-22'} *-->
# WebRTC coding style guide
@ -166,7 +166,7 @@ Prefer `webrtc::CallbackList`, and manage thread safety yourself.
The following smart pointer types are recommended:
* `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
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
`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
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
@ -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
occasion. Prefer to use interfaces when that makes sense, and consider
`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