以下内容引用自
http://blog.youkuaiyun.com/u012175089/article/details/51078360
本文来自肥宝游戏,引用必须保留文末二维码!!!
好几天没写文章了,周一整理自己刚修好的旧电脑,发现一本书《高质量C++编程指南》。因为最近在写游戏服务端的战斗,所以这个立刻就吸引肥宝了。看了几天,深深感觉获益良多啊。于是把笔记和自己的经验写下来,分享给大家。
一、写出漂亮易读的程序
中学时代上课很喜欢做笔记,但是肥宝几乎没看过自己的笔记,不是肥宝懒,是因为肥宝字太丑了。
后来成为一个程序员,以为这些代码都是电脑输出,统一字体,就不用这么纠结了。谁知道代码更需要写得漂亮,因为需求是不断在变化的,bug也是不断地涌现。无论出于工作还是学习,你总会经常看回自己写的代码,比起中学时代看自己的笔记的概率高多了。
可能一个功能,在开始的时候会经常看到,不会觉得难看,但是一周之后呢?一个月后呢?一年后呢?更离谱的是,有一次肥宝收到一个以前的工作的人的电话,问肥宝代码的问题,那个时候肥宝都离职了几个月了。就算现在,旧的游戏依然会有新的人维护,他们经常拿肥宝一两年前写的代码来问肥宝。肥宝觉得维护一些写得丑的代码,跟自己每天被迫跟一个300斤的大肉参来个法式湿吻那么恐怖。
怎样才算漂亮的代码,怎样才算丑的代码?下面给出一些小规则:
文档的结构:
【1】头文件用来声明,cpp文件用来定义。声明和定义分开,不但可以让代码更清晰、方便阅读,同时,如果在某些场合,代码不能公开,只向用户提供头文件和二进制的库即可。通常这样的情况下,头文件和源文件是在不同目录的
【2】为了防止头文件被重复引用,应当用 ifndef/define/endif 结构产生预处理块。这个宏定义必须讲究,如果重复了,可能会出现莫名其妙的问题。肥宝个人习惯是工程名+目录+文件名。
例如:
【3】用#include<file>引用标准库头文件(编译器从标准库目录开始搜索),用#include"file.h"引用其他文件(编译器从工作目录开始搜索)【4】一般情况下h文件只写声明,不写定义。写内联函数时不要包含for,递归等复杂操作,不要超过5行。因为消耗很大,而且调试不方便。
【5】尽量少用局部变量。
【6】按照实际意义区分目录,一个目录内超过10个文件,要考虑是否拆分。
程序的风格:
良好的格式有助于阅读和维护。一般情况下,我们使用的IDE,入Visual Studio、Eclipse、XCode等,本身生成的代码都是符合良好的风格的,尽量使用代码提示功能,有助于形成良好风格。肥宝平时用得比较多的是Visual Studio,所以下面的风格也是这个软件的。
【7】在每个类声明之后加空行,每个函数定义结束之后都要加空行。
【8】在一个函数体内,逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔。
【9】一行代码只做一件事情,只定义一个变量,只写一条语句。这样的代码容易阅读,并且方便于写注释。
【10】if 、for 、while 、do 等语句自占一行,执行语句不得紧跟其后。不论执行语句有多少都要加 {}。这样可以防止书写失误。
【11】尽可能在定义变量的同时初始化该变量(就近原则),放久了很容易忘记。
不良风格的代码:
良好风格的代码:
【12】关键字之后要留空格。
例如 const 、virtual 、inline 、case 等关键字之后至少要留一个空格,否则无法辨析关键字。
例如 if 、for 、while 等关键字之后应留一个空格再跟(,以突出关键字。
【13】函数名之后不要留空格,紧跟'(',以与关键字区别。'('向后紧跟,右括号、逗号、分号向前紧跟,紧跟处不留空格。,之后要留空格,如Function(x, y, z) 。如果‘; ’不是一行的结束符号,其后要留空格,如 for (int i = 0; i < 10; i++)
【14】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符, 如“= ”、“+= ” “>= ”、“<= ”、“+ ”、“* ”、“% ”、“&& ”、“||”、“<< ”, “^ ”等二元操作符的前后应当加空格。
【15】一元操作符如“!”、“~ ”、“++ ”、“-- ”、“& ”(地址运算符)等后不加空格。
【16】“[]”、“.”、“->”这类操作符前后不加空格。
【17】对于表达式比较长的 for 语句和 if 语句,为了紧凑起见可以适当地去掉一些空格。
如 for (i=0; i<10; i++)和 if ((a<=b) && (c<=d)) ,或者太长的话可以适当换行。【18】程序的分界符‘ {’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐。
这个是C++的风格,java的风格是{紧跟出现前的代码
【19】 { }之内的代码块在‘{’右边一个制表符处左对齐。
不良风格:良好风格的代码
如果出现嵌套的{},则使用缩进(按Tab键)对齐,如:
【20】代码行最大长度宜控制在 70 至 80 个字符以内。代码行不要过长,否则要拉来拉去很麻烦
【21】长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。拆分出的新行要进行适当的缩进,使排版整齐,语句可读。表达式内尽量不要套多层表达式。
本文来自肥宝游戏,转载引用请加链接http://blog.youkuaiyun.com/u012175089/article/details/51078360
更多文章来自肥宝游戏
注释
程序块的注释常采用“/*…*/”,行注释一般采用“ //…”。
【22】注释是对代码的“提示”,而不是文档。注释风格统一。
【23】 如果代码本来就是清楚的,则不必加注释。
【24】边写代码边注释,改代码后要同时修改注释
【25】 注释应当准确、易懂,防止注释有二义性。 错误的注释有害。
【26】 尽量避免在注释中使用缩写,特别是不常用缩写。
【27】 注释的位置应与被描述的代码相邻,可以放在代码的上方或右方,不可放在下方。在VS中,在上方注释后,下面所有代码的提示都受到影响的,所以优先放后方
【28】 当代码比较长,特别是有多重嵌套时,应当在一些段落的结束处加注释,便于阅读。
【29】 对于思路复杂的代码,可以把思路写在注释里面,否则别人看起来很蛋疼。另外一些设计思想也应该写下来。
对于一些业务多变,而且往往不合常理的需求,一定要多写注释。例如游戏代码中,很多策划特意要求做的特殊处理,有的是为了坑玩家,更多的是为了体验。这东西看代码是看不到任何思路的。当你发现某个地方明明可以用很简洁的代码写,却硬是要用一些很傻比的方法的时候,很可能不是那个人没经验或者偷懒,而是策划要求造成的。所以像游戏这种系统,一定要多谢注释,但改的时候一定要跟着改,否则,呵呵呵呵呵呵呵呵呵呵呵。
类的风格
【30】 类的public函数写在前面,private数据写在后面。不要把什么都往一个类里面扔,要注意这个类本身的含义。命名
命名并没有统一的标准!很多公司都有自己的一套标准。
【31】标识符应该可以望文生义,长度尽量小,信息尽量大
【32】 命名规则尽量跟系统风格保持一致
【33】 不要出现紧靠大小写区分的标识
【34】 尽量不要出现标识符完全相同的局部变量和全局变量
【35】 同一个项目的代码下,即使在不同工程内,也不要出现完全相同的文件名称,这是VS的一个bug,调试起来会在同名文件间跳来跳去。
【36】 变量的名字应使用名词或者形容词+名词,函数的名字应该使用动词或者动词+名词
【38】 使用反义词去命名互斥意义的变量或函数
【39】 尽量避免使用数字
下面是肥宝所在的项目的一些规范:
(1)类名开头大写,结构以S开头,类以C开头,数组用Seq开头,字典类型用Dict开头,指针用Ptr结尾。
(2)变量和参数用小写开头,之后每个单词开头大写。变量名一般就不加类名这些前缀后缀了。
游戏代码的命名是个蛋疼的事情,作为游戏程序员,碰到的很多名词是无法翻译的。例如诛邪、神兽、涅槃、貔貅、修为、境界、法力,很多很多,有些时候你可能翻译了一个单词出来,过几天一个新的功能,你会发现意义好像差不多的。这个时候我们经常会用拼音,通俗易懂啊。
还有个更蛋疼的事情,游戏的功能是多变的,策划的需求一天一个样,例如某个货币叫做荣誉,做好了功能,过几天这个荣誉要改名为修为,另外的地方突然有个货币叫做荣誉。这个时候你不得不跟着把名称也改掉。否则过一个星期,没几个人看得懂,而且跟客户端,PHP后台,运营等交流也很蛋疼,大家无法同步。所以,命名的时候不一定要按他们给出来的来命名,最好用一些跟中性的而又不违反语义的单词,另外自己弄一张汉语-英文-功能对照表。还有文档的功能名称通常跟上线后的功能名称完全不同的。
二、从习惯开始优化程序的性能
表达式和基本语句
【40】如果代码行中的运算符比较多,用括号确定表达式的操作顺序,避免 使用默认的优先级。
【41】 不要编写太复杂的复合表达式。【42】不要有多用途的复合表达式。
【43】不要用数学表达式的方法来写程序中的表达式
【44】不可将布尔变量直接与 true、false 、 1、0 进行比较。
【45】应当将整型变量用“==”或“!=”直接与 0 比较。而且最好把0写在左边,其他数字也是
【46】不可将浮点变量用“==”或“!=”与任何数字比较。 因为float和double都有精度限制。
【47】指针变量与Null比较,最好不直接写。(其实肥宝一直习惯直接)
循环语句的使用
【48】长循环放里面,短循环放外面,因为会打断循环体,
为了验证这个效率具体差别到什么程度,写了一段测试代码,发现上万次循环的时候才有几毫秒的差别,可能dosomething函数太简单的原因。不过肥宝觉得有些时候比较难把短循环抽出去的话,就没必要太刻意了。
本文来自肥宝游戏,转载引用请加链接http://blog.youkuaiyun.com/u012175089/article/details/51078360
更多文章来自肥宝游戏
【49】不可在 for 循环体内修改循环变量,防止 for 循环失去控制。尤其注意erase的用法
我们游戏服务端宕机有一半是这个引起的,每次新人来了都跟他们说,说了还是会犯错。
【50】 switch语句中每个case后面必须加break,必须加defualt。【51】 少用慎用goto。
肥宝觉得,业务层的代码,直接禁用吧!
常量
【52】尽量使用常量来表示程序中经常出现的数字或字符串
【53】 需要对外公开的常量放在头文件,内部使用的放在源文件。
很多人喜欢把常量放在同一个文件中,但是多了之后改动一下,多个地方要编译。我们游戏曾经加一个错误码要编两个小时,后面改成配置了,这个自己把握吧。
【54】函数声明是,参数要写完整,命名要恰当。
【55】 参数最好加上&,可以大量节省对象构造和析构的时间。
就这样一个函数,没加&的时候,执行时间是现在的三倍,可以看肥宝前一篇文章 MMO游戏技能攻击区域的计算3--效率分析
【56】只做传值的参数最好加上const
【57】不要使用太多参数,参数太多,可以弄一个结构包起来,让程序清晰。
【58】尽量不要使用类型和数量不确定参数
【59】默认参数要慎用,而且不要太多。
例如:
后来因为业务变化,函数改成
因为调用地方太多,有的地方改漏了,在外网正式服出现了问题被人投诉才知道。
后来肥宝的解决办法是把默认参数都去掉,然后一个个找错,是在没办法了。
返回值
【60】 函数返回和函数名字在语义上要一致
例如:
写的人不会觉得什么,但是用的人可能就会用错了。
【61】在函数体内,容易出现return或者throw的分支尽量写在前面,可以省掉剩下的判断
【62】如果返回值是一个对象,要考虑效率
基础类型并没有构造这些步骤,省不了多少,看情况那种简洁用哪种。
【63】函数功能要单一,不要设计多用途的函数
【64】函数体规模要小,50行内,超过了最好拆分一下。
本文来自肥宝游戏,转载引用请加链接http://blog.youkuaiyun.com/u012175089/article/details/51078360
更多文章来自肥宝游戏
内存管理
【63】内存没分配成功,通常用指向这个内存的指针检测是否为空。
肥宝觉得,内存分配不成功,后面的处理已经不重要了。整个系统内存都爆了,宕机什么的是必然的了。然后运营会收到各种投诉,查错,赔偿,维护一大堆事情陆续有来。
【64】内存后,要养成初始化的习惯。
不要以为检测一个数字为负数就能确定还没初始化,如果碰上重复使用的那块内存,真的不知道是什么。
【65】动态内存的申请与释放必须配对,防止内存泄漏。
【66】用 free 或 delete 释放了内存之后,立即将指针设置为 NULL,防止产 生“野指针”。
【67】指针消亡,并不代表指向的内存被释放,内存被释放,并不代表指针为null。
【68】指针声明的时候,要么指向具体内存,要么设置为null,否则是随机值,可能if(p == Null)不起作用的。
【69】new一个对象的代价大,还是初始化后重用的大呢?
结果效率一样,但是如果执行了上面被注释的init函数后,时间消耗大大提高。初始化可能更加占消耗
【70】内联函数是用于实现的,声明的时候不用写。在头文件实现的函数自动成为内联函数
【71】 重载、内联、缺省参数、隐式转换等机制展现了很多优点,但是这些 优点的背后都隐藏着一些隐患。不要总是想着用什么高级方法,不要为了用而用。很多时候,先写出来,后面再优化就好了。当然,可能还没写好,需求就变了。
【78】类的构造函数和析构函数可能有很多隐藏的操作,不一定适合做成构造函数
构造函数、析构函数、赋值函数
【79】赋值函数只是位拷贝而不是值拷贝,如果其中有指针就很可能出问题。而且会造成内存泄漏。【80】构造函数有个特殊的初始化方式叫“初始化表达式表”(简称初始化表),初始化表在函数参数表之后,在函数体{}之前。
如果类存在构造关系,必须在初始化表里面初始化。
带有const的属性必须在初始化表里面初始化。
一个类初始化的时候,如果属性不是基础类型,放在初始化表来初始化,效率更高。
其他的建议
【81】不要一味提高效率,应该更多考虑程序的可读性,可维护性。如果你也是做游戏的话,很可能你的游戏根本没几个人玩,永远碰不到这个瓶颈,哈哈哈哈哈!【82】优化程序的时候,要充分考虑游系统的特性,找出瓶颈所在。例如一个MMO游戏,在初期推广的时候,很多新玩家,经常在某个时段某个功能很多人同时玩,这个要注意。到了后期的功能,可能会很少人接触,但是在后来往往有很多跨服功能,几乎所有玩家在同一个服玩,这些都是要考虑的问题。
【83】最好的优化应该是从业务级别开始。很多东西计算量固定在那,怎么减都减不了的。需要考虑从业务级别入手。【84】先优化数据结构,再优化算法
【85】有时候时间效率和空间效率对立,要做出折冲的方案,私人告诉你,现在内存很便宜,硬盘更便宜。但是系统启动读数据,可能会很慢很慢。【86】避免编写技巧性很高代码。
【87】当心变量发生上溢或下溢,数组的下标越界。
【88】尽量使用标准库函数,不要“发明”已经存在的库函数。【89】尽量不要使用与具体硬件或软件环境关系密切的变量。
最后:
还有很多很多的优化方式,不过限于本人的水平,只整理了这么多。路很长,道无涯,苦练七十二变,才能笑对八十一难,努力吧,少年!