| 有些人会想：只要程序运行结果好，就不管原程序编得怎样。但绝对不是这样的。软件不是一次性就作完的，有必要做修改，扩展等管理。所以原程序要尽量作成易看懂，管理方便。
这样做，第一是为了软件开发者方便，其次还会影响到软件的性能。管理不方便的程序不会作出好的软件。
希望通过这篇文章能学到好的编程习惯。要理解这文章的内容，你至少要懂得1个开发工具语言。这里举例说明的都是C语言，但你对C语言没有了解也不要担心。这里说明的是原理而不是特定的语言。
1. 语句要结束得彻底---(冒号；)
程序员经常有的失误之一是忘记在语句结束后加一个冒号。这样的问题点不易发现，时而让程序员不知所措。编程时要时时注意每个语句是否以冒号结束，虽然不是所有语言都以冒号结束。下面有忘记点冒号的例子。
int main(void)
{
/* 没有冒号，导致问题*/
printf("Hello World!\n")
return(0);
}
很多的人犯这样的错误。不到几条的程序是不难发现这样的问题，但1000条以上的程序里呢？查找那忘记写冒号了的语句不会是很容易的事。记住，结束一条语句，一定要写冒号，如同一般文章结束后点句号一样。
还有一种关于冒号的失误是不该写冒号的时候写冒号。有经验的程序员看到下面例子会觉得好笑，但笔者确实看到了很多这样的失误。
/* main() 后面不该写冒号 */
int main(int argc, char *argv[]);
{
printf("Hello World");
return(0);
}
函数或Method后面是不该写冒号的。
2. 要适合使用空格和tab键
C语言是不分辨空格的，因此程序也可以不需要空格一直写下去，但这样的程序会是谁都看不懂的"很有难度"的程序，请看以下例子：
if(x==0) {a=b=c=d=MAX; x++;}
这样写，也许会节省空间，但不仅别人，编程的本人也会很难看懂。程序要写得容易看懂！
if(x == 0)
{
a = b = c = d = MAX;
x++;
}
这样写，看起来不很清楚吗？程序要有确切的空格才容易看得懂。
3. 统一使用大括号和切断方式
每个程序员使用大括号({})和改行的方式都有自己的习惯，这样，把程序移交给别人继续做的时候，会出现混乱。比如象以下例子：
int main()
{
int x = 1;
int y = 10;
while(x < y ){
printf("Value of x is %d\n",
x);
x++;
}
}
有些程序员会这样写大括号：
int main()
{
int x = 1;
int y = 10;
while(x < y )
{
printf("Value of x is %d\n",
x);
x++;
}
}
笔者是喜欢第二种方式。因为一段语句的开始和结束很明显。我们不能要求每个程序员都用某一种方式来编程，但一个程序里一定要统一。还有，看别人编的程序时要想到他人编程的习惯也许与你不同。
4. 不乱用if语句
有些人很喜欢用“if”语句，如下：
if(a == 0)
{
a++;
return(a);
}
if(a == 1)
{
a += 5;
return(a);
}
if(a == 2)
{
a += 10;
return(a);
}
if(a == 3)
{
a += 20;
return(a);
}
if(a == 4)
exit(1);
有没有比这更好的办法呢？else if语句？不是。好的方法是用“switch-case”语句来写简便的程序：
switch(a)
{
case 0: a++;
return(a);
case 1: a += 5;
return(a);
case 2: a += 10;
return(a);
case 3: a += 20;
return(a);
default: exit(1);
}
如果没有与a一致的值，会执行default里定义的作业，上面的例子是要执行结束。
5. 不乱用程序切断（Block）
很多人经常乱用程序切断。使用三个以上的切断是比较难以看懂的程序。请看下面例子：
int a = 10;
int b = 20;
int c = 30;
int d = 40;
if(a == 10)
{
a = a + d;
if(b == 20)
{
b = b + a;
if(c != b)
{
c = c + 1;
if(d > (a + b))
printf("Made it all the way
to the bottom!\n");
}
}
}
这也许是夸张了，但确实有很多人真的这样做。那如何写得更好一点呢？一种方法是用函数来分写：
void next(int a, int b, int c, int d)
{
if(c != b)
{
c = c + 1;
if(d > (a + b))
printf("Made it all the way to
the bottom!\n");
}
}
int main()
{
int a = 10;
int b = 20;
int c = 30;
int d = 40;
if(a == 10)
{
a = a + d;
if(b == 20)
{
b = b + a;
next(a, b, c, d);
}
}
return(0);
}
要这样写，也许会增加工作量，但程序编得结构化，容易看懂，而且如果函数做得更好，也可以在其他地方再使用。
6. 写好注释
要养成写注释的习惯。特别是别人难以理解的程序或变量一定要注释，一个月后，也许你自己也需要看那注释呢。
int x = 100;
int y = 1000;
if(x < y)
a = 0;
else
a = 1;
你能知道上面的程序意味着什么？如果不知道变量x,y和a指的是什么，那么很难理解。让我们给它标个注释再看吧：
/*
* 检测损益的程序
*/
int x = 100;
/* x 是卖书的总额*/
int y = 1000
/* y是做书本的费用*/
int a;
/* 确认是否有赢利*/
/* 比较x和y: */
if(x < y)
/* 1指损失 */
a = 1;
else
/*0指赢利 */
a = 0;
这样注释，不懂C语言的人也会看懂各语句意味着什么，各变量指的是什么。写注释是好习惯，但不要什么都注释。注释是为了好理解，不是为了写长编文章。
int profit = 1;
/* 赢利等于1 ?? */
int loss = 0;
/* 亏损等于 0 ?? */
/* 如果赢利等于1 */
if(profit == 1)
/* 打印出“得赢利啦”??*/
printf("We made a profit!\n");
/* 如果不是 */
else
/*打印出“我们亏损啦”*/
printf("We made a loss!\n");
这样注释是浪费时间。一般是定变量或变量值的时候需要注释，还有说明程序的目的，使用某个函数，procedule等的时候也需要。
7. 起名要合理
程序，变量，procedure，structure等名一定要跟它的内容联系起来，变量不要起名如”x”,”y”,”z”
也许你会说笔者在上面举的例子里也用了x,y等，可笔者这样做的理由是他不牵涉到其他程序，实际开发软件的时候，笔者当然会使用有意义的变量名。请看下面例子：
void x(int a, int b)
{
int z;
z = a + b;
printf("z is %d\n", z);
}
在这，我们可以知道x做什么，但不知道它意味着什么。a,b,z也一样。让我们稍微改过来再看吧：
void sum_of_ages(int jacks_age, int jills_age)
{
int total_age;
total_age = jacks_age + jills_age;
print("total_age is %d\n", total_age);
}
虽然没有注释，但容易看出来要做什么。起名起得好，没有注释也可以。
8. 确认Buffer
要时时确认对设定的排列或变量的大小，以避免数据混乱或导致系统出问题。请看下面使用者输入数据的例子：
char city[10];
/* 为都市名称的排列 */
printf("Enter a city name: ");
scanf("%s", city);
printf("City is %s\n", city);
在这里，都市名称设定为10字（英文字）以内。如果使用者输入10字以上的都市名称会怎么样呢？可以说程序失败或覆盖Buffer里面的数据。不管怎样，不要做冒险的事，你要检查文字的长度：
char city[10];
/*为都市名称的排列*/
printf("Enter a city name: ");
fgets(city, sizeof(city), stdin);
printf("City is %s\n", city);
上面已修改的程序是：如果使用者输入10字以上的都市名，只接受Buffer能接受的长度为止，其外的会不接受。
9. 绝对不相信使用者
这是很重要的规律。千万不要相信将要使用你的软件的人，不要认为使用者会按你希望的方式来操作，反而把他们想成专门发现程序毛病的人。举例说，上面的程序就是为了那些输入都市名更长的的使用者而确认文字长度的。
象C语言需要明确的数据形式的开发工具使用者，要记住确认输入数据形式和程序数据形式是否一致，不然会出现问题。
磨刀不误砍材工
以上的编程习惯是为你自己的方便。实际编程之前，要多做准备（分析，设计）。虽然稍麻烦，但为了编出易懂整齐的程序，不要舍不得花时间准备，不然以后会需要更多的时间来修改，扩展你的程序的。
|