Skip to content
This repository has been archived by the owner on Mar 13, 2024. It is now read-only.

Create Posts “2023-11-10-google-c-规范-翻译” #22

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
141 changes: 141 additions & 0 deletions _posts/2023-11-10-google-c-规范-翻译.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,141 @@
---
title: Google C++ Style Guide 翻译
date: 2023-11-10T01:36:02.394Z
last_modified_at: 2023-11-10T01:36:02.405Z
excerpt: 对Google
C++规范进行翻译,并进行总结归纳。翻译自:https://google.github.io/styleguide/cppguide.html。
categories:
- 文章翻译
tags:
- C++
- 代码规范
header:
overlay_image: https://picsum.photos/1920/640
caption: "来源: [**Lorem Picsum**](https://picsum.photos/)"
teaser: /assets/images/site/default-teaser.png
---
## 背景

C++是 Goolge 开源项目中很常用的一种语言。正如许多 C++ 开发者所认为的,C++ 有很多强大的功能,但是这些也会带来相应的复杂度,这使得 C++ 代码很容易产生漏洞并难以阅读和维护。

本风格指南的目标正是通过详细描述应该和不应该做的规范来控制 C++ 的复杂度。这些规范能够在保证代码库易于管理的同时,允许开发者高效的使用 C++ 的功能进行开发。

*风格*,或者说是可读性,是被用于管理 C++ 代码的规范。实际上风格这个词有些偏颇,因为规范的包含范围远超出单纯的源文件格式的范畴。

由谷歌开发的多数开源项目遵循本指南中的要求。

需要注意,本指南并不是 C++ 教程:本指南假设读者熟悉 C++ 开发语言。

## 风格指南的目标

为什么需要本代码规范呢?

我们认为有几个关键目标是本指南应该达成的。指南中的每个规范有其对应的关键**目标**。通过把这些目标呈现出来,我们希望能够使得讨论更有依据,并向我们庞大的社区解释为什么需要某个规范和为什么做出某个决策。如果能够明白每个规范所实现的目标,那么什么时候应该删去某个规范,或为了改变规范需要哪些论点和代替方案,这些问题都会更加明晰。

当下,本风格指南的目标包括:

- **风格应该具有足够的重要性**:风格规范带来的收益必须足够大,才有足够的理由要求所有的工程师记住该规范。所谓的好处是通过对比没有规范要求的代码库得到的,因此如果一个规范针对某个非常有害的做法,但是人们通常不会这样做,那么这个规范的收益就很低。本准则主要解释了为什么某些规范没有被收录,而不是解释已经被本指南收录的规范:例如,`goto` 语句违背了下述的很多准则,但是该语句已经很少被使用了,因此本指南并没有讨论该语句。

- **为代码阅读者进行优化,而非编写者**:这里假设,代码库(和提交到代码库中的独立组成部分)的开发工作是会持续相当长的时间的。这就导致,花费在代码阅读上的时间多于代码编写的时间。我们明确为了平均水平的软件工程在阅读、维护、调试代码库中代码时的体验进行优化,而不是对编写代码时的体验进行优化。“为了读者留下线索”是本准则的一个常见子集:当代码中出现令人惊讶或不常见的情况时(例如,指针所有权转移),为阅读者留下文字提示是很重要的(`std::unique_ptr` 在调用处明确描述了所有权的转移)。

- **和已有代码保持统一**:在整个代码库中使用统一的风格能够让开发者关注其他(更重要)的问题。并且,一致性还使得自动化成为可能:一些格式化代码或调整 `#include` 的工具,只有在代码与工具预期保持一致时才能正确工作。在很多情况下,属于“一致性”准则的规范可以归结为“直接选一个就好,停止内耗”;在这类规范上允许灵活处理所带来的潜在价值超过了在这类规范上争论的价值。不过,一致性是存在限制的;当没有明确技术支撑和长期方向时,一致性能很好的帮助我们决策。一致性通常不能作为使用旧风格的理由,而不考虑新风格带来的好处,或者代码库随时间推移逐渐靠近新风格的趋势。
- **适当的与庞大的 C++ 社区保持一致**: