谷歌C++编码规范读书笔记

前言

今天快速翻看了谷歌C++编码规范http://zh-google-styleguide.readthedocs.org/en/latest/google-cpp-styleguide/contents/,学到了一些东西。

对于这个规范,我不会100%接收,比如里面的变量命名规范就跟工作项目的代码冲突了,还有谷歌建议switch中的每个块要加上{}等等。
我在看文档的过程中,把学到的新东西记录下来,有些以前就习以为常的编码习惯,我就不再记录,比如析构函数要用virtual关键字,用sizeof(varname)代替sizeof(type)等。这里的摘抄,都是我认为具有通用性的建议。

正文

  • 所有头文件都应该使用 #define 防止头文件被多重包含, 命名格式当是: PROJECT_PATH_FILE_H_
  • 能用前置声明的地方尽量不使用 #include.
  • 复杂的内联函数的定义, 应放在后缀名为 -inl.h 的头文件中.
  • 使用标准的头文件包含顺序可增强可读性, 避免隐藏依赖: C 库, C++ 库, 其他库的 .h, 本项目内的 .h.
  • 不要在 .h 文件中使用匿名名字空间.
  • 不要将嵌套类定义成公有, 除非它们是接口的一部分, 比如, 嵌套类含有某些方法的一组选项.
  • 禁止使用 class 类型的静态或全局变量: 它们会导致很难发现的 bug 和不确定的构造和析构函数调用顺序.
  • 构造函数中只进行那些没什么意义的初始化, 可能的话, 使用 Init() 方法集中初始化有意义的 (non-trivial) 数据.
  • 类的每个区段内的声明通常按以下顺序:
    1. typedefs 和枚举
    2. 常量
    3. 构造函数
    4. 析构函数
    5. 成员函数, 含静态成员函数
    6. 数据成员, 含静态数据成员
  • 我们不允许使用缺省函数参数.
  • 我们禁止使用 RTTI.
  • 对于迭代器和其他模板对象使用前缀形式 (++i) 的自增, 自减运算符.
  • 整数用 0, 实数用 0.0, 指针用 NULL, 字符 (串) 用 ‘\0‘.
  • 关于函数的命名,永远不要用省略字母的缩写,比如不能将count缩写成cnt。
  • 函数声明处注释描述函数功能; 定义处描述函数实现.
  • 向函数传入 NULL, 布尔值或整数时, 要注释说明含义, 或使用常量让代码望文知意.
  • 如果函数声明成 const, 关键字 const 应与最后一个参数位于同一行.
  • 如果有些参数没有用到, 在函数定义处将参数名注释起来:
  • return 表达式中不要用圆括号包围.
  • 预处理指令不要缩进, 从行首开始.
时间: 2024-08-06 16:01:08

谷歌C++编码规范读书笔记的相关文章

《编码》读书笔记:从无到有构建计算机系统

1 简单的电报系统: 按键.发声装置,电池和一些导线即可构成: 当电报机的键按下时,发生器的电磁铁将可动棒拖下发出“滴”的声音:当键放开时,棒弹回初始位置,发出“嗒”的声音.快速的“嘀嗒”为点,慢速的则为划. 2 继电器 电磁式继电器一般由铁芯.线圈.衔铁.触点簧片等组成的.只要在线圈两端加上一定的电压,线圈中就会流过一定的电流,从而产生电磁效应,衔铁就会在电磁力吸引的作用下克服返回弹簧的拉力吸向铁芯,从而带动衔铁的动触点与静触点(常开触点)吸合.当线圈断电后,电磁的吸力也随之消失,衔铁就会在弹

《Python从小白到大牛》第5章 Python编码规范

俗话说:"没有规矩不成方圆".编程工作往往都是一个团队协同进行,因而一致的编码规范非常有必要,这样写成的代码便于团队中的其他人员阅读,也便于编写者自己以后阅读. 提示关于本书的Python编码规范借鉴了Python官方的PEP8编码规范^1和谷歌Python编码规范^2. 命名规范 程序代码中到处都是标识符,因此取一个一致并且符合规范的名字非常重要.Python中命名规范采用多种不同.不同的代码元素命名不同,下面分类说明一下. 包名.全部小写字母,中间可以由点分隔开,不推荐使用下划线.

读谷歌编码规范所想到的

这几天看了很多文章,其中有一篇<为什么谷歌要执行严格的代码编写规范>让我深有感触. 不得不承认,以前一直认为编码规范没什么用处,甚至有时候觉得浪费开发人员的工作时间. 在同另一个公司合作共同开发项目的过程中,偶然的查看了他们的代码,统一的命名方式.简洁的描述.详细的参数注解,让我没花多少时间就轻松的看懂了它们的业务逻辑,曾经被觉得微不足道的编码规范不经意间让我震惊. 有时候我们打心里抵触.拒绝一些东西(假如它确实是美好的),可能一部分原因是太久的时间依旧让我们感受不到它的魅力,于是花谢了,城倾

《从零开始学Swift》学习笔记(Day 57)——Swift编码规范之注释规范:

<从零开始学Swift>学习笔记(Day 57)--Swift编码规范之注释规范:文件注释.文档注释.代码注释.使用地标注释 原创文章,欢迎转载.转载请注明:关东升的博客 前面说到Swift注释的语法有两种:单行注释(//)和多行注释(/*...*/).这里来介绍一下他们的使用规范. 文件注释 文件注释就在每一个文件开头添加注释,文件注释通常包括如下信息:版权信息.文件名.所在模块.作者信息.历史版本信息.文件内容和作用等. 下面看一个文件注释的示例: /* Copyright (C) 201

《编写可维护的 Javascript》读书笔记(附录 A 部分):Javascript 编码风格指南(1)原始值

记录一下比较有用的编码规范(该指南是基于 Java 语言编码规范和 Javascript 编程规范,同时结合作者 Nicholos Zakas 的个人经验和喜好). 一些关于格式(包括缩进.行的长度.运算符间距.括号间距.对象直接量.注释.单行注释.多行注释等类似的规范)的规范这里不做记录. A.3 原始值 // 好的写法 var name = "Nicholos"; // 不好的写法:单引号 var name = 'Nicholos'; // 不好的写法:字符串结束之前换行 var

世界是数字(读书笔记)

<世界是数字的>是世界顶尖计算机科学家Brian W.Kernighan写的一本计算机科普类读物,简明扼要但又深入全面地解释了计算机和通信系统背后的秘密,适合计算机初学者和非计算机专业的人读.这真的是一本好书,借Google常务董事长的话: 对计算机.互联网及其背后的奥秘充满好奇的人们,这绝对是一本不容错过的好书. 对于一个计算机已经学了N年的专业人士来说,这本书也许简单了点,不过我还是认真过了一遍,发现也有一定的收货,因为一个人很难掌握本领域里的所有知识,或多或少会有一些欠缺,总会有一些你以

《你必须知道的.NET》读书笔记三:体验OO之美

一.依赖也是哲学 (1)本质诠释:"不要调用我们,我们会调用你" (2)依赖和耦合: ①无依赖,无耦合: ②单向依赖,耦合度不高: ③双向依赖,耦合度较高: (3)设计的目标:高内聚,低耦合. ①低耦合:实现最简单的依赖关系,尽可能地减少类与类.模块与模块.层次与层次.系统与系统之间的联系: ②高内聚:一方面代表了职责的统一管理,一方面又代表了关系的有效隔离: (4)控制反转(IoC):代码的控制器交由系统控制而不是在代码内部,消除组件或模块间的直接依赖: (5)依赖注入(DI): ①

读书笔记2014第4本:程序员修炼之道-从小工到专家(第七、八章)

第七章 在项目开始之前 36 需求之坑不为收集需求,挖掘它们.有一种能深入了解用户需求,却未得到足够利用的技术:成为用户.与用户一同工作,以像用户一样思考.描述需求文档时,要使用项目术语表.用WEB来收集和管理需求. 37 解开不可能解开的谜题遇到不可能解决的问题时,退一步问问自己如下问题:1)有更容易的方法吗?2)你是在设法解决真正的问题,还是被外围的技术问题转移了注意力?3)这件事情为什么是一个问题?4)是什么使它如此难以解决?5)它必须以这种方式完成吗?6)它真的必须完成吗? 38 等你准

自然语言处理一些读书笔记和自己的思考。

在知乎上搜索相关问题,有人推荐<数学之美>,之前粗略看过一次,这次想重新看一下并且做个读书笔记.下面是关于自然语言理解方面的一些读书笔记和自己的思考. 一. 自然语言处理历史: 自然语言处理最初发展的20多年里,相关科学家都极力通过电脑模拟人脑,试图用这种方式来处理人类语言,但是这种方式被证明是行不通的,成功几乎为零.NLP发展的第二阶段是70年代之后,科学家们终于找到了基于数学模型和统计的方法. 第一阶段的时候,学术界对人工智能和自然语言理解的普遍认识是:要让机器完成翻译或者语音识别等等,必