本文共 993 字，大约阅读时间需要 3 分钟。

写代码的时候太随意，近期在自己的代码中发现一个有意思的Bug。代码中有一个只写了一半的语句，但是编译器却一点警告也没有直接放过了。

为了说明问题，简单复现当时问题的示范代码如下：

  1 #include "stdio.h"

  2 

  3 int a;

  4 int b;

  5 

  6 int main(void)

  7 {

  8     a =

  9     b = 123;

 10     printf("a = %d\n",a);

 11     printf("b = %d\n",a);

 12 

 13     return 0;

 14 }

 15 

编译运行的结果：

GreydeMac-mini:exp_29 greyzhang$ gcc exp_29.c 

GreydeMac-mini:exp_29 greyzhang$ ./a.out 

a = 123

b = 123

看一下执行的结果似乎就知道是什么问题了，肯定是编译器是别人一行代码拆成了两行来写了。即使是这样，在过去的这么多年工作中，这种连续赋值的用法是很忌讳使用的。以至于现在我都不知道这个是否可以用。为了验证自己的想法，把代码修改一下：

  1 #include "stdio.h"

  2 

  3 int a;

  4 int b;

  5 

  6 int main(void)

  7 {

  8     a = b = 123;

  9     printf("a = %d\n",a);

 10     printf("b = %d\n",a);

 11     

 12     return 0;

 13 }   

 14 

编译运行的结果：

GreydeMac-mini:exp_29 greyzhang$ gcc exp_29.c 

GreydeMac-mini:exp_29 greyzhang$ ./a.out 

a = 123

b = 123

从执行结果上看，这两种方式是等价的。

其实，这种换行的用法在后来自己进行能力提升学习的过程中是遇到过的。但是，通常这种换行而不使用续航符号的时候都是在函数声明的时候，因此接触到的是十分少的。从软件的安全性考虑，我个人是比较支持换行必须使用续航符号的。简单的一个符号能够避免不少问题，还能够简化软件的调试难度，让软件更容易维护。即使现在，从语法或者编译器的角度支持这种自由的换行，从个人编码风格上也应该注意这一点。

说起来，这种风格还是让我想到了多年前我十分依赖的编程语言Perl的。至于Perl的使用，那真得另说了。

转载地址：https://greyzhang.blog.csdn.net/article/details/71249223 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！