谷歌C++风格指南之通俗译文(译文保留版权,勿转载)

Background
背景

C++ is the main development language used by many of Google‘s open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain.
//C++特性强大 -> C++难读难维护
很多谷歌的开源项目把C++作为编程语言。每个C++程序员都知道C++有很多强大的特性,但是越强大,C++的难度也变得越大。难度就招来了Bug,同时代码也变得难读和难以维护。

The goal of this guide is to manage this complexity by describing in detail the dos and don‘ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.
//这篇文章会告诉你哪些该做。
这篇指导的目标是,告诉你写C++代码时该做的和不该做的,通过这些来管控C++的难度。在保证程序员可以高效使用C++特性的同时,使得代码库可以维护,这就是这些准则所存在的意义。

Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.
//代码风格的定义不仅仅局限在源代码文件的格式上。
代码风格,或者说所谓的可读性,是我们掌控C++代码的约定。因为这些约定不仅仅局限在源代码文件的格式上,所以风格这个术语有点用词不当。

One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another‘s code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use "pattern-matching" to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.
//推行一致性,不要临时改变风格。
强制的推行一致性是我们保持代码库可控的一个方式。使其他程序员很容易看懂你的代码是很重要的。如果我们保持统一的风格和遵循约定,那么我们可以使用“模式-匹配”来更容易的推断:那些变量与不变量的真正含义。建立普通、必要的习语和模式使得代码更通俗易懂。在某些情况下,改变到某种风格会更好,但我们还是让这些风格准则保留原样,使得他们保持一致。

Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.
//不用随便使用C++高级特性
这篇指导文章将说说另一个问题:对C++特性的滥用。C++拥有很多高级特性,它是个很大规模的语言。一些情况下,我们限制或者是禁止去使用某种特性。这样做是为了代码能够简单,同时避免各种错误和问题。这篇指导文章列出了这些特性,解释了为什么应该限制使用它们。

Open-source projects developed by Google conform to the requirements in this guide.
谷歌公司的开源项目都符合这篇导文中提出的要求。

Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.
注意这篇文章不进行C++教学:我们假设你熟悉这门语言。

时间: 2024-10-09 02:53:16

谷歌C++风格指南之通俗译文(译文保留版权,勿转载)的相关文章

【翻译】Ext JS——高效的编码风格指南

原文:ExtJS - Efficient coding style guide 作者:Raja 切勿使用"new"关键字:在Ext JS中,使用"new"关键字来创建一个组件或类的实例是一种错误的做法,因为这没有遵循组件的生命周期.应该使用Ext.create方法来创建对象,例如: 错误: var obj = new Ext.panel.Panel(); 正确: var obj = Ext.create('Ext.panel.Panel'); 初始化直接量:不要直接

python代码风格指南:pep8 中文翻译

摘要 本文给出主Python版本标准库的编码约定.CPython的C代码风格参见?PEP7.本文和?PEP 257 文档字符串标准改编自Guido最初的<Python Style Guide>, 并增加了Barry的?GNU Mailman Coding Style Guide的部分内容.本文会随着语言改变等而改变.许多项目都有自己的编码风格指南,冲突时自己的指南为准. 本文给出主Python版本标准库的编码约定.CPython的C代码风格参见PEP7. 本文和PEP 257 文档字符串标准改

Google C++编程风格指南

一.头文件 1. #define的保护:所有头文件都应该使用#define防止头文件被多重包含(multiple inclusion),命名格式: <PROJECT>_<PATH>_<FILE>_H_ 为保证唯一性,头文件的命名应基于其所在项目源代码树的全路径. 2.头文件依赖:使用前置声明(forward declarations)尽量减少.h文件中#include的数量.避免多米诺骨牌效应 e.g.头文件中用到类File,但不需要访问File的声明,则头文件只需前置

Swift 编程风格指南(raywenderlich.com 版本)

官方 raywenderlich.com Swift 编程风格指南 本文版权归 raywenderlich.com .The Official raywenderlich.com Swift Style Guide项目以及所有贡献者所有.译者翻译仅供知识传播使用. 本风格指南的目标是让Swift代码更简洁.可读更强. 语言 推荐使用跟苹果API文档风格统一的英语. 推荐: var color = "red" 不推荐: var colour = "red" 空白 使用

来自 Google 的 R 语言编码风格指南

本文转自Xiao Nan的博客 R语言是一门主要用于统计计算和绘图的高级编程语言. 这份 R 语言编码风格指南旨在让我们的 R 代码更容易阅读.分享和检查. 以下规则系与 Google 的 R 用户群体协同设计而成. 概要: R编码风格约定 文件命名: 以 .R (大写) 结尾 标识符命名: variable.name, FunctionName, kConstantName 单行长度: 不超过 80 个字符 缩进: 两个空格, 不使用制表符 空白 花括号: 前括号不折行写, 后括号独占一行 赋

PSR代码风格指南

代码风格指南 本手册是基础代码规范(PSR-1)的继承和扩展. 为了尽可能的提升阅读其他人代码时的效率,下面例举了一系列的通用规则,特别是有关于PHP代码风格的. 各个成员项目间的共性组成了这组代码规范.当开发者们在多个项目中合作时,本指南将会成为所有这些项目中共用的一组代码规范. 因此,本指南的益处不在于这些规则本身,而在于在所有项目中共用这些规则. RFC 2119中的必须(MUST),不可(MUST NOT),建议(SHOULD),不建议(SHOULD NOT),可以/可能(MAY)等关键

google C++编程风格指南之头文件的包含顺序

google C++编程风格对头文件的包含顺序作出如下指示: (1)为了加强可读性和避免隐含依赖,应使用下面的顺序:C标准库.C++标准库.其它库的头文件.你自己工程的头文件.不过这里最先包含的是首选的头文件,即例如a.cpp文件中应该优先包含a.h.首选的头文件是为了减少隐藏依赖,同时确保头文件和实现文件是匹配的.具体的例子是:假如你有一个cc文件(linux平台的cpp文件后缀为cc)是google-awesome-project/src/foo/internal/fooserver.cc,

Google Java编程风格指南(转)

目录 前言 源文件基础 源文件结构 格式 命名约定 编程实践 Javadoc 后记 前言 这份文档是Google Java编程风格规范的完整定义.当且仅当一个Java源文件符合此文档中的规则, 我们才认为它符合Google的Java编程风格. 与其它的编程风格指南一样,这里所讨论的不仅仅是编码格式美不美观的问题, 同时也讨论一些约定及编码标准.然而,这份文档主要侧重于我们所普遍遵循的规则, 对于那些不是明确强制要求的,我们尽量避免提供意见. 1.1 术语说明 在本文档中,除非另有说明: 术语cl

JavaScript 编码风格指南

A.1  缩进 // 4个空格的层级缩进 if (true) { doSomething(); } A.2  行的长度 // 每行限于80个字符,超出则在运算符后换行,缩进2个层级(8个空格) doSomething(argument1, argument2, argument3, argument4, argument5); A.3  原始值 // 字符串使用双引号及长字符串的链接 var name = "Nicholas", longStr = "this is a lo