关于代码规范的一点心得

  看了别人的博客后,觉得自己有些想法很模糊,或许写下了就清晰了。主要是和c语言代码规范相关的一点想法。

  1、注释

  a、文件头注释;

  b、外部接口注释;

  以上两点注释最好用模板生成,且要仔细填写。这个地方是新手最容易忽略和犯错的地方。

  c、函数内部注释;

    这个注释的写法跟个人习惯及软件框架都有关系。我们软件的框架决定我们的一个模块(或者说文件)比较大,一个函数比较长(加注释不超过200行),所以有时候一个函数中要做几件事(大家都知道这样不好)。我写注释的方法是这样:一件事写一个注释。这个规则要达到的目的是:一、只看注释就可以知道这个函数的做了几件事;二、注释对函数内部逻辑有隔断作用,随时可以将一个注释下的内容单独拿出来封个接口。

  如果说外部接口的注释是给调用者看的,那么函数内部注释就给维护人员看的。建议不要对代码逻辑进行解释型的注释,而应注释该代码是干什么的。解释性质的注释意味着代码难以理解,难以理解的代码本身是坏味的代码(除了一些为了有效率要求而不得不采用的简洁而难懂的代码以外)。只要一个代码不出问题,维护人员可能永远不会看它实现的逻辑,但是只这段代码出现在屏幕上,维护人员总是要看下这段代码是干什么的,看看跟自己要解决的问题是否有关。

  2、合法性判断

  a、参数合法性判断;

  刚开始写代码时,特别小心,总是担心判断不够,结果导致函数开头总是一大长串判断合法性的语句,看起来特别丑。后来思考及学习了一段时间后,觉得有以下几点值得琢磨一下:一、空指针必查;二、外部接口要对参数或其他方式获取的外部数据进行取值范围进行检查;三、内部接口只对数组越界、空指针检查,不对外部数据进行检查。

  b、返回值判断

  有时候需要调用一些公用接口,这种接口在很多地方都会调用,本身很稳定,如果判断一下返回值吧,觉得画蛇添足,不判断吧,又不放心。我觉得返回值的判断是这样的:一、要用到的返回值肯定是要判断的,比如需要根据返回值显示提示的情况;二、不判断可能导致程序崩溃的情况。

  c、数组下标

  对于新手来说最容让程序挂的是数组下标越界和空指针。举个曾今让自己困惑过的例子:

for (i= 0; i < num; i++)
{
   array[i] =  .....
}

   相信大家经常看到这样的代码吧,以前我总想这样改:

for (i= 0; i < num; i++)
{
    if (i < 0 || i >=  ARRAY_LEN)
    {
         break; // 或者直接return
    }    
    array[i] =  .....
}

   实际上应这样改: 

if (num < 0 || num > ARRAY_LEN)
{
     return;
}
for (i= 0; i < num; i++)
{
    array[i] =  .....
}

   还有一些字符串操作时,也有类似的情况。当时的困惑的是若判断了(按第一种方式)就会每次循环判断一次,好累赘,不判断应该没太可能有问题,因为一般情况下i小于num的情况下应该没问题,但心里总有个坎。现在看来当时的困惑还是有点萌的。

  3、格式

  对于新手来说,总是因为学习、熟悉一些基本的知识或规则而分散了注意力,导致容易出现一些低级bug,工作效率低。代码格式是一个典型。别人说编码格式就是程序员的脸面。刚开始的时候我是觉得格式并不重要的,为了完成任务,格式常常被忽略,但是现在觉得缺一个空格都非常刺眼。建议:认真对待自己敲出的每一个字符。习惯一段时间后,会发现格式不仅不会分散自己的注意力,反而然自己有了一个好的办公环境。

    目前想到和代码规范相关的就是以上这些了,有何不妥的地方欢迎指正。

 

转载于:https://www.cnblogs.com/nixiaoxianggong/p/5104211.html

你可能感兴趣的:(关于代码规范的一点心得)