1,程序员之路──为何要学好C语言

 

学习任何知识,循序渐进总是最好的方式。不幸的是,很多人明知这个道理,却总是想走所谓的捷径。如果你是一个刚刚开始学习编程的中学生,或者你是一个刚刚进入计算机学院的本科生,又或者你是一个决心在计算机领域有所建树的初学者,你一定迫切地想知道,学习计算机技术,究竟应该从哪里下手。

  我的建议是:数学、英语、C语言。

  数学和英语的重要性已经不需要我来强调,大家也许从幼儿园就开始学习它们了,请时刻把它们放在最重要的位置,无论你是否学习计算机。

  为什么C语言如此重要?我们从学习方法开始说起。书本上描述的东西,倘若不经过我们的亲自实践,是难以被彻底消化吸收的。计算机组成原理讲解了浮点数的格式,如果我们能看到并分析内存或寄存器中某个浮点数的表示,那比单纯的纸上谈兵要强一千倍;数据结构与算法似乎很难,如果你能把书上的例子实现出来,然后把习题做完,只需啃完一本好书,你也可以是算法高手;操作系统原理其实不仅仅是原理,只有做一些内核方面的实验才能真正有深刻理解;还有许多新潮的技术,比如JavaEE、PHP、Ajax、.NET等等等等,很多高手学习这些技术只需要很短的时间,不必说,他们肯定是C语言的高手。C语言几乎是一切计算机技术的通用工具,包括计算机的各种基本理论。没有精通C语言的决心,就不要涉足计算机领域。

  为什么是C语言而不是C++不是Java不是其它?因为C语言最简单。你需要掌握一个语言工具,但也许并不需要“面向对象”、“模板”、“函数重载”等等一大堆概念。C语言足够低级,非常非常地贴近计算机的底层结构,不会让你迷失在概念的汪洋大海。除了“指针”,C语言没有真正意义上的难点,而“指针”,恰恰是理解计算机底层结构精髓的关键所在。

  所以,初学者们不必思考应该学什么,等把C语言精通了,你自己便会知道下一步如何去走。如果你对操作系统内部感兴趣,你便可以试着研究一下Unix的内核,除了C语言,你还需要一些汇编语言和保护模式的知识;如果你对算法感兴趣,那么恭喜你,C语言足够使用了;如果你对Windows编程感兴趣,去看看《Windows程序设计》吧,作者清楚的告诉你“只需要C语言的基础”;如果你对任何其它语言感兴趣,尽管去学吧,不过还是建议先学C++,因为你需要一些“面向对象”的知识。

  至于如何学习C语言,应该注意哪些方面,我会在下一篇文章《程序员之路──如何学习C语言》中详细描述。

 

2,程序员之路──如何学习C语言

 

学习C语言不是一朝一夕的事情,但也不需要花费十年时间才能精通。如何以最小的代价学习并精通C语言是本文的主题。请注意,即使是“最小的代价”,也绝不是什么捷径,而是以最短的时间取得最多的收获,同时也意味着你需要经历艰苦的过程。

一、要读就读好书,否则不如不读


  所有初学者面临的第一个问题便是:如何选择教材。好的开始是成功的一半,选择一本优秀的教材是事半功倍的关键因素。不幸的是,学校通常会帮你指定一本很差劲的C语言课本;而幸运的是,你还可以再次选择。

  大名鼎鼎的谭浩强教授出了一本《C语言程序设计》,据说发行量有超过400万,据我所知,很多学校都会推荐这本书作为C语言课本。虽然本人的名字(谭浩宇)跟教授仅仅一字之差,但我是无比坚定地黑他这本书的。这本书不是写给计算机专业的学生的,而是给那些需要考计算机等级考试的其它专业学生看的。这本书的主要缺点是:例子程序非常不专业,不能教给你程序设计应该掌握的思考方式;程序风格相当地不好,会让你养成乱写代码的恶习;错误太多,曾经有人指出过这本书的上百个错误,其中不乏关键的概念性错误。好了,这本书我也不想说太多了,有兴趣大家可以百度一下:)

  Kernighan和Ritchie的《The C Programming Language》(中译名《C程序设计语言》)堪称经典中的经典,不过旧版的很多内容都已过时,和现在的标准C语言相去甚远,大家一定要看最新的版本,否则不如不看。另外,即使是最经典最权威的书,也没有办法面面俱到,所以手边常备一本《C语言参考手册》是十分必要的。《C语言参考手册》就是《C Reference Manual》,是C语言标准的详细描述,包括绝大多数C标准库函数的细节,算得上是最好的标准C语言的工具书。顺便提一句,最新的《C程序设计语言》是根据C89标准修订的,而《C语言参考手册》描述的是C99标准,二者可能会有些出入,建议按照C99标准学习。还有一本《C和指针》,写得也是相当地不错,英文名是《Pointers on C》,特别地强调指针的重要性,算是本书的一个特点吧。不过这本书并不十分适合初学者,如果你曾经学过C语言,有那么一些C语言的基础但又不是很扎实,那么你可以尝试一下这本书。我相信,只要你理解了指针,C语言便不再神秘。

  如果你已经啃完了一本C语言教材,想要更进一步,那么有两本书你一定要看。首先是《C Traps and Pitfalls》(中译名《C陷井与缺陷》),很薄的一本小册子,内容非常非常地有趣。要注意一点,这本书是二十多年前写成的,里面提到的很多C语言的缺陷都已被改进,不过能够了解一些历史也不是什么坏事。然后你可以挑战一下《Expert C Programming》(中译名《C专家编程》),书如其名,这本书颇具难度,一旦你仔细读完并能透彻理解,你便可以放心大胆地在简历上写“精通C语言”了。

  切记一个原则,不要读自己目前还看不懂的书,那是浪费生命。如果你看不懂,那你一定是缺失了某些必需基础知识。此时,你要仔细分析自己需要补充哪些内容,然后再去书店寻找讲述的这些内容的书籍。把基础知识补充完毕再回头来学习,才会真正的事半功倍。

二、Unix/Linux还是Windows,这是个很大的问题


  不同的编程环境会造就出不同思维的程序员。Windows的程序员大多依赖集成开发环境,比如Visual Studio,而Unix程序员更加钟爱Makefile与控制台。显而易见,集成开发环境更容易上手,在Windows上学习C语言,只需要会按几个基本的Visutal C++工具栏按钮就可以开始写Hello, World!了,而在Unix下,你需要一些控制台操作的基本知识。有人也许认为Unix的环境更简洁,但习惯的力量是很大的,大家都很熟悉Windows的基本操作,而为了学习C语言去专门装一个Unix系统,似乎有点不划算。

  对于一个只懂得Windows基本操作、连DOS是什么都不知道的新手而言,尽快做一些有趣而有意义的事情才是最重要的。用C语言写一个小程序远比学习ls、cat等命令有趣,况且我们要专注于C语言本身,就不得不暂时忽略一些东西,比如编译链接的过程、Makefile的写法等等等等。

  所以我建议初学者应该以Visual C++ 6.0(不是VisualC++ .NET)或者Dev C++作为主要的学习环境,而且千万不要在IDE的使用技巧上过多纠缠,因为今后你一定要转向Unix环境的。Visual C++ 6.0使用很方便,调试也很直观,但其默认的编译器对C标准的支持并不好,而Dev C++使用gcc编译器,对C99的标准都支持良好。使用顺带提一下,很多大学的C语言课程还在使用Turbo C 2.0作为实验环境,这是相当不可取的,原因其一是TC 2.0对C标准几乎没有支持,其二是TC 2.0编译得到的程序是16位的,这对今后理解32位的程序会造成极大的困扰(当然,用djgpp之类的东西可以使TC 2.0编译出32位程序,不过那过于复杂了)。

  等你学完一本C语言的教材,你一定要转向Unix平台继续学习,几乎所有的C语言高级教程都是基于Unix平台的(比如《C专家编程》)。转变的过程是痛苦的,你需要面对的是各种纷繁复杂的命令,完全不同于Windows平台的思考方式,但是这种痛苦是值得的。Unix与C是共生的,Unix的思考方式和习惯更加符合C语言的思考方式和习惯。在Unix下,你可以找到无数优秀的源代码供你尽情阅读,你可以方便地查看某个库函数的联机手册,还可以看到最优秀的代码风格(说到代码风格,我会专门写一篇文章详细叙述)。

  归结起来就是一句话:初学C语言,建议使用Windows系统和集成开发环境,在准备向“高手”方向努力时,请先转向Unix平台。

三、万事俱备,你就是东风


  书已选定,环境配置完成,正所谓万事俱备,只欠你自己的努力了。请从书的前言开始,仔细地阅读手头的教材,很多人看书喜欢直接从第一章开始看,这是错误的做法。前言是作者对整本书的大体介绍,作者一般会告诉你需要什么基础才能够顺利阅读本书,这可以帮助你检验自己的基础知识是否已经具备。看完前言,还要浏览一下目录,了解一下书的整体结构,顺便给自己安排一下学习计划。

  学习C语言,必需注意每一个细节,书上的例子代码一定要自己亲自敲一遍,编译执行输出都跟书上说的一致才能算是学完了一个例子,如果不一致,就要仔细找原因。出了书本上有的例子,自己还要“创造”一些例子,比如学习运算符优先级的时候,可以写几个相同的表达式,在不同的位置加上括号,看看有哪些不同的行为,比如*p++和(*p)++,又比如a = b == c、(a = b) == c和a = (b == c)等等。自己抄的书上的例子以及改造之后的例子,还有自己“创造”的例子,都应该仔细地归类保存,并且要在源代码中写上简短的注释,阐述这个例子的意图。 

  例子之后就是习题了,我建议初学者把所有的习题都独立做一遍,然后对照答案的代码,看看自己的代码有那些不足,再试着修改自己的代码。很多人不重视习题,这是极大的错误,因为作者通常会在习题中说明一些重要的道理,而不是单纯地检验前面的知识。

  也许你认为这样学习太慢,其实不然。学得细致就不用走回头路,等你学到后面才发现自己前面没搞清楚,那才是真的得不偿失。一般说来,整本书读完,你应该完成数千行乃至上万行的代码,无论是原封不动照抄书上的,还是自己心血来潮写就的,都是今后继续学习的一笔财富。以我自己举例,阅读《Windows核心编程》时(我只阅读了3/4的内容),除了抄书上的代码,还自己写了很多例子,一共有5574行(用unix下的wc工具统计),时隔多日,我早已记不清Windows的系统编程了,但只要花几分钟翻出以前的代码看看,便会重新了然于胸。所谓好记性不如烂笔头,就是这个道理。

  仔细读书、认真抄写源代码、独立完成习题外加更进一步的实验,最后将所有的代码留下,成为自己的经验和财富,绝对的辛苦,也绝对的事半功倍。当然,这种方式只适合学习需要精通的技术,如果不是学习C语言,你还要具体情况具体分析。

  写到最后,还有非常非常重要的一点没有提及──代码风格,从最开始学习就必须强迫自己模仿最优秀的代码风格。因为代码风格太重要内容也太多,我会用专门的一篇文章来详细讨论,请大家关注《程序员之路──关于代码风格》。

 
 

3,程序员之路──关于代码风格

 

优秀的代码风格如同一身得体的打扮,能够给人以良好的印象。初学程序设计,首先必须建立良好的编程习惯,这其中就包括代码风格。本文就代码风格中的几个重点问题进行了讨论,并在文后给出了一份优秀的代码作为风格模板。代码风格不必花费太多专门的时间研究,在使用中不断模仿模板代码,轻轻松松就能写出“专业的代码”。

 

一、80字符,代码行极限

  无论时空怎么转变,世界怎样改变,一行80字符应始终铭记心间。古老的Unix终端以80列的格式显示文本,为了让源代码与手册具有最佳的可读性,Unix系统始终坚持着80列的传统。80列不多不少,足够写出一行有意义的代码,同时也足够显示在终端屏幕,足够打印在A4纸上。虽然时至今日,我们的屏幕分辨率早已足够高,一行能够显示的内容远超超过80字符,但我们的优秀传统已经形成──几乎所有的Unix/Linux内核源代码以及联机用户手册都严格地遵守着80列极限。如果你正好在使用Windows平台下的Dev C++,你是否有注意到代码编辑框里那条细细的灰色竖线?不错,那正是代码行极限。除了HTML、XML等冗长繁复的标记式语言,几乎所有的语言都需要严格遵守代码行极限,这包括C、C++、Java、C#、Python、PHP等等。不过有时,比如当PHP跟HTML打交道的时候,这个限制是可以暂时放松的。过长的代码行总是不好的,好的代码要始终保持苗条的身材。

 

二、Tab还是Space,众说纷纭的缩进方式

  代码离不开缩进,关于缩进主要有两个争论,一个是该用空格(Space)还是用制表符(Tab),另外一个是该用4格缩进还是8格缩进甚至都不是。

  先来谈谈Space与Tab的问题。坚持用Space的程序员会告诉你,如果你从来都不用Tab,那么你的代码放到所有的地方看都是一样的。没错,这是用Space缩进的优点,可惜的是,这是它唯一的优点。代码层次越多,内层代码最前面的缩进便越多,这意味着你需要敲很多很多次空格。即使你能忍受不厌其烦地按空格键直到它坏掉,你也一定会被IDE总是自作聪明地插入一些Tab字符的行为烦恼不已。建议总是使用Tab缩进,因为几乎所有的代码(不仅仅是C代码)都在使用Tab缩进。

  Tab到底是4格还是8格?这是Tab缩进会被某些人诟病的根源。当你写程序时使用的Tab大小与别人读程序时使用的Tab大小不同时,再漂亮的排版也会变得杂乱无章。标准的Tab是8格的,而不幸的是,几乎所有的Windows平台下的IDE,包括Visual Studio、Dev C++,甚至跨平台的Eclipse等,都默认使用4格Tab。我使用的FreeBSD系统的所有的内核源代码都采用8格缩进,所以我一直坚持使用8格缩进。也许你不习惯太大的间距,如果不是在Unix平台下,或者不是C语言,那就采用4格Tab吧。如果你在Unix下编写C代码,使用8格的标准Tab是更好的习惯。

 

三、折行原则,容易被忽略的角落

  既然有代码行极限,很多情况下我们不得不断开一个完整的代码行,这就带来了一个问题:折行后应该如何缩进?好的做法是,第一次折行后,在原来缩进的基础上增加1/2的Tab大小的空格,之后的折行全部对齐第二行。可能这样的文字描述过于晦涩了,还是举个例子罢(以8格缩进为例):

if (value > a && value > b && value > c && value < d && value < e && value < f
    value < h && value < h) { /* 注意折行后的缩进 */
value = value + 1;
  value = value * value * value * value * value * value * value * value
     * value * value + value * value * value * value * value * value
     * value * value; /* 注意再次折行后的缩进 */
}

  显然这个段代码没有任何实际用处,只是为了说明折行缩进而编造的。

 

四、无处不在的空格,无处不在的空行

  需要空格的位置有:
  1)if、while、switch等关键字与之后的左括号(之间。
  2)左花括号{之前。
  3)双目运算符两侧,例如p == NULL。
  4)逗号,与分号;之后,例如for (i = 0; i < 10; i++)。   

  不要空格的位置有:
  1)函数名与之后的左括号(,包括带参数的宏与之后的左括号(,例如max(a, b)。
  2)分号;与冒号:之前。
  3)左括号(右边,右括号)左边,例如if (p == NULL)。

  需要空行的位置有:
  1)函数的定义之前、函数的定义之后
  2)一组联系紧密的代码段之前和之后

  这些规则并不完全,当你碰到上面没有列举出来的情况时,请参考本文提供的模板代码。

 

五、左花括号的争议──换行乎?不换乎? 

  这又是一个仁者见仁智者见智的问题了。从使代码更清晰的角度看,作为代码段开头标识的左花括号{应该另起一行:

if (p == NULL)
{
printf("error!/n");
exit(0);
}

  可是,这看起来实在不够紧凑,所以大部分的C代码(至少Unix上如此)都采用了这样的方式:

if (p == NULL) {
printf("error!/n");
exit(0);
}

  我的建议是采用后者,这会使你的代码显得更加紧凑,也更加专业。需要说明一个特例,在定义函数时,我们总是要给左花括号{换行:

static int
maxint(int a, int b)
{
return a > b ? a : b;
}

 

六、坚持美观、灵活对待

  代码风格远远不止上面提到的五点,事实上,很多公司都有规定的代码风格,包括命名规则、缩进规则等。如果你在一个开发团队中,应该始终以团队的标准为主,而如果你只是在学习C语言并试着形成自己的代码风格,我将在这里给一份最专业的源代码供你参考。你的任何疑问,在这份代码里一定可以找到答案:Code Style(注意查看时将Tab设置为8格)。这份代码来自优秀的FreeBSD操作系统内核源代码(版本6.2),你一定不会置疑它的权威性。更多内容请参考FreeBSD内核代码编写规范,你也许需要一些耐心才能读完这篇英文文档。

版权声明:本文为yuaqua原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/yuaqua/archive/2013/06/11/3131979.html