![](https://img-blog.csdnimg.cn/20201014180756916.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
编码规范
听听那冷雨~
猿
展开
-
0不要拘泥于小节(了解哪些东西不应该标准化)
只规定需要规定的事情:不要强制施加个人喜好或者过时的做法;1. 有些问题只是个人喜好,并不影响程序的正确性或者可读性,所以这些问题不应该出现在编程规范中;2. 应该在每个源文件乃至每个项目中都使用一致的格式,因为同一段代码中要在几种编程风格之间换来换去是非常不舒服的;3. 常见不应该标准化的东西:(1) 不要规定缩进多少,应该规定要用缩进来体现代码的结构;(2) 不要强制行的...翻译 2018-04-05 23:49:00 · 321 阅读 · 0 评论 -
组织和策略问题:1高警告级别干净利落的进行编译
高度重视警告:使用编译器的最高警告级别;因该要求构建是干净利落的(没有警告);理解所有警告。通过修改代码而不是降低警告级别来排除警告;1. 编译器是你的朋友,如果它对某个构造发出警告,这经常说明你的代码中存在潜在问题;2. 排除警告的正确做法:(1) 把它弄清楚;(2) 改写代码以排除警告,并使代码阅读者和编译器都能更加清楚,代码是按照编写者意图执行的;3. 即使程序一开始似...翻译 2018-04-06 00:28:25 · 256 阅读 · 0 评论 -
组织和策略问题:2使用自动构建系统
一次按键就解决问题:使用完全自动化(单操作)的构建系统,无需用户干预即可构建整个项目;1. 我们都不应该将时间和精力浪费在机器可以干得更快,更好的事情上;自动的,可靠的,单操作的构建是非常有必要的;2. 成功的构建应该无声无息,不产生任何警告;理想的构建过程不会出现噪声,只会出现一条日志信息:构建成功;3. 构建有两种模式:增量构建(重新构建上次发生改变的部分)和完...翻译 2018-04-06 00:40:16 · 170 阅读 · 0 评论 -
组织和策略问题:3使用版本控制系统
好记性不如烂笔头:请使用版本控制系统(VCS),永远不要让文件长时间地登出;在新的测试单元通过之后,应该频繁登入。确保登入的代码不会影响成功; 1. 几乎大一点的项目都需要一个以上的开发人员和(或)一周以上的开发时间;在这样的项目中,将需要比较同一文件的各个历史版本,以确定修改是何时(以及/或者由谁)进行的,需要控制和管理源代码的变更;2. 如果有多个开发人员,他们将会并行地进行修改,...翻译 2018-04-06 02:10:41 · 149 阅读 · 0 评论 -
组织和策略问题:4在代码审查上投入
审查代码:更多的关注有助于提高质量;亮出自己的代码,阅读别人的代码;相互学习,彼此都会受益; 1. 好的代码审查过程对开发团队有很多方面的益处:(1) 通过来自同伴的良性压力提高代码质量;(2) 找出错误,不可移植的代码(如果适用)和潜在的扩展问题;(3) 通过交流思想获得更好的设计和实现;(4) 快速培养新同事和初入门着;(5) 在团队中形成共同的价值观和集体主义;...翻译 2018-04-06 02:20:52 · 150 阅读 · 0 评论 -
编码规范
编码风格1. 命名规则:类名 大写C开头,其后每个单词首字母大写,单词之间不加任何分隔符 CRenderComponent结构名 大写S开头,其余规则同类名 SRectangle枚举名 大写E开头,其余规则同类名 ENodeType类的公有函数 第一个单词首字母小写,且必须为动词,其后每个单词首字母大写,单词之...原创 2018-03-29 21:27:54 · 636 阅读 · 0 评论 -
函数应该怎么写?
1. 注释不一定能提高函数的可读性和可维护性;(1) 很多人在修改代码的时候,注意力都放在代码,功能上,修改代码之后忙着马上编译运行;只要功能和预期的一致就觉得可以了,置于与代码匹配的注释,往往会忘记同步修改;(2) 一旦注释与代码不一致,以后维护该代码的程序员就会非常困惑,不知道应该相信注释还是该相信注释;(3) 解决办法:解决问题的办法是不用注释,让代码本身来解释代码的功能;例如将...转载 2018-04-06 20:18:44 · 1338 阅读 · 0 评论