写代码的时候太随意,近期在自己的代码中发现一个有意思的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的使用,那真得另说了。