Update caveats for thread_local usage, particularly around the risk of destruction order issues.
Provide explicit guidance for situations where bit_cast may be a better fit than reinterpret_cast.
Emphasize that kConstant-style naming can still be used for const automatic variables that are initialized at runtime, but only if the resulting variable has the same value with each evaluation (i.e. it does not depend on runtime inputs).
Clarify what sorts of details belong in file-level comments vs comments for individual abstractions.
Update TODO examples to reflect the preferred styling, from most preferred to least preferred.
These style guides are copies of Google's internal style guides to
assist developers working on Google owned and originated open source
projects. Changes should be made to the internal style guide first and
only then copied here.
Unsolicited pull requests will not be merged and are usually closed
without comment. If a PR points out a simple mistake — a typo, a broken
link, etc. — then the correction can be made internally and copied here
through the usual process.
Substantive changes to the style rules and suggested new rules should
not be submitted as a PR in this repository. Material changes must be
proposed, discussed, and approved on the internal forums first.
tituswinters
commented
11 months ago
thread_localusage, particularly around the risk of destruction order issues.bit_castmay be a better fit thanreinterpret_cast.constautomatic variables that are initialized at runtime, but only if the resulting variable has the same value with each evaluation (i.e. it does not depend on runtime inputs).These style guides are copies of Google's internal style guides to assist developers working on Google owned and originated open source projects. Changes should be made to the internal style guide first and only then copied here.
Unsolicited pull requests will not be merged and are usually closed without comment. If a PR points out a simple mistake — a typo, a broken link, etc. — then the correction can be made internally and copied here through the usual process.
Substantive changes to the style rules and suggested new rules should not be submitted as a PR in this repository. Material changes must be proposed, discussed, and approved on the internal forums first.