代码规范小结（一）

「爱情、让人受尽委屈。」 2022-08-17 13:28 170阅读 0赞

写这个小结的原因就是自己深有感触，决定记下来以免重蹈覆辙~

最近在改一些Flash脚本，改到一个1400行左右的脚本，大致浏览了一遍几乎就蒙了…这代码把我写醉了

好在1000多行，还能硬着头皮看，下面开始总结问题

1.      命名不规范。

这个我想干过这行的人都遇到过，或者也都写过类似的代码。比如起个名字，a1,a2,a3,a4,a5或者i,j,k,l,m,n,q,p。如果只是临时用一下做个循环处理，还可以接受，但是要是一个成员变量就过分了。你让其他的人怎么看你的代码，过几天自己都忘了是什么意思了。

那好，有的人开始起名字，newsj=data;

什么意思？新数据<=>new  shu  ju，不要笑，我看到的就是这样的代码。

起码咱们都用英文，或者整个公司都是汉语（hanyu）拼写我也可以理解为企业文化啊，英汉结合是不是太潮了啊。。。变量不要怕长咱们就起个名字叫newData行不行。

其实，在看一些引擎的源码时，虽然单词不认识，但是可以查。所有的成员变量都是以m或者m\_开头，类名用C开头，接口用I开头，枚举用e开头，指针用p开头，string或const char\*用s开头，布尔用b开头，int用n开头，这样所有的类型不都是一目了然。

至于具体的命名一般就是驼峰法和匈牙利命名法。

比如一个布尔类型的变量表示是否加载场景，起名bIfLoadingScence或者b\_ifLoadingScence,我是觉得这样看起来舒服多了。

如果有一天咱们用汉字编程，这篇博客就删了吧。。

2.      写注释

如果你的代码写的非常优美，逻辑非常清晰，那么…

你也得至少写一些注释。何况我们很多人写的代码就是一坨一坨的…又难看，还不写注释，那真是痛苦的不行，起码为了项目能延续下去，在必要的地方我们至少要写一些注释，比如函数的功能概括，具体算法的核心思路等等。

这里还要强调一些变量的注释，因为你的英语可能不怎么样，或者别人的英语不怎么样

如果你修改别人的代码，最后把你改的地方标注出来，如果改动比较大，那就干脆帮忙改到底，把相关的东西也改的规范些，别简单的删除或注释个变量，或者改一个名就不管其他的代码了。

3.      代码组织

我并不确定一个类到底要按照什么顺序去放你所有的函数，但是起码的构造，析构要放在突出的位置，最好就是最前面。那变量也应该集中在一个位置，放在最前面或者最后面，public和private，protected分开。功能类似或者有逻辑上紧密联系的最好也放在一起，要不然没有一个好的IDE的话，分分钟累死人的，很多时候脚本文件就没有像visual studio这样强大的工具可以到迅速找到你要的文件或者变量。尽量让.h和.cpp函数的顺序一致。

4.      函数参数不要随便用可接受任何类型的变量，除非你在写一个框架或者一个库。

其实我并没有多少经验或者发言权说这个问题，但至少我在脚本遇到一个参数或者C++遇到一个auto的话，我还是会觉得比较头疼的。

5.      脚本文件尽量不要在多个对应的文件帧上写代码

既然决定要使用脚本文件写逻辑，我们就尽量把代码交给单独的脚本文件，如果在一个有10多帧媒体文件或者模型文件，到处写代码，会让之后的调试很无奈。甚至后面的人都不知道你在脚本的帧上写了这么多代码，如果是帧调用，起码写上注释。。。

6.      函数命名

一般来说，应该是按照函数功能命名比较可取，但是对于前端的一些函数可以采用onbuttonclick的这种命名，如果功能比较复杂还是强烈建议写注释，要不然还是很难理解功能。

关于这次改代码暂时就想出来这些建议（这些已经够坑了），以后慢慢添加吧~