假设有一种编程的方法,能够克服所有的困难和改正所有的错误,而且能够避免重写代码,我相信我们都会使用这种方法。因为没有一种完美的编程方法, 我们能做的事情就只能是看我们周围的程序员是如何做的,哪些是正确
的,哪些是错误的。有一些编程的方法是我从实际工作中总结而来的,也确实感到它们能够帮助我养成良好的编程习惯。其中最重要的一件事情就是记住,当你看到这些经验的时候,不要认为他们太简单和基础,觉得一种方法是不值得学习的。很多程序员认为检查错误和写程序注释是浪费时间。而我认为,这些经验能够帮助我们节省时间和精力。在实践过程中,我了解到,我能够更快的编写代码,代码也更加的有效率。
做最坏的打算
假设你是一个超级程序员,你的代码永远都不会有错误。但是,如果你的完美的代码没有得到完美的数据,事情将会如何?你的代码假设一个指针是合法的,或者它会把一个声音文件当作一个图片来处理?基本上来说,一段代码
不能假设任何事情。C语言又一个标准的函数 assert, 它能够用来捕获错误。每次你的代码接收到用户数据,请注意要先确认数据是你所预想的。如果不是,使用assert并且打印消息来解释出现了什么错误。这是很重要的,这样你就能够让任何阅读你的程序的人了解到,什么是正确的数据,什么是错误的。百分之九十的错误都是一些简单的错误。所以,不要让这种错误影响你的程序浪费调试人员的时间,而只需要简单的在那些地方给出一个assert, 就能够避免。百分之九十的时候它能够容易的被改正。而另外百分之十的时候,它能够在变成一个大的错误之前被调试人员注意到并且改正。不论你采用哪种编程语言,你编写的第一个程序一般都是打印一条消息。把这个打印消息的功能作为你的程序中一个基本的函数,能够简单的打印任何错误。这样,程序就能分辨不明显的错误,你也能在任何错误可能出现的地方使用这个打印错误消息的函数。这样,就能够节省寻找错误的时间,从而让改正错误的时间减短。
注释
不要企图记住你的代码是用来做什么的。在你编写完一段程序几个月之后,你不会记得在编写程序的时候的想法,也不会记得什么代码是用来干什么的。所以,写注释是一个好的方法,特别是当你需要别人来阅读你的代码,或者是为了你半年之后还能记起来这段代码的目的。如果有一个同事告诉你,你的代码有一个错误,你将不得不重新检查并且改正它。如果你能够通过注释来回忆起什么代码用来做什么,你就能快一点找到并且改正错误。这个方法也是比较简单的,只需要注明你的那一段代码是做什么的,这就够了。而如果你不这么做,其他的阅读你的程序的人将看不懂它的意思,不知道变量是用来做什么的,哪些复杂的计算又是用来做什么的。如果你说明了它们的意义,就简单多了。比如,看这样的代码if "(frmp>10)", "(plist.bdown & x03)", "(plist.y > pond.y)"就比看注释要复杂的多。当你写注释的时候,你会得到两种好处。
任何人都能明白你希望一段代码去做什么,而且,如果这段代码有错误,阅读代码的人就能发现,它没有执行你在注释中希望它去做的事情,那样就能尽快的发现错误和改正它。注释是程序员最重要的工具之一。而且所有的语言都支持注释。所以,记住,要写注释。
文档
当我在写一个文档的时候,我记得我花了很多篇幅来写一段关于系统和模块的文档。这个文档是正确的,但是却是没有用的。因为,没有人读过它。很多人都忘记了还有这篇文档,而是在需要的时候来问我,让我来解释给他们。
这种方法也不错,它比查阅整个文档快多了。很少有机会有人会花上一大段时间来通读整个文档。所以说,我当时写文档的时间是浪费了。而且,如果这个系统和模块要做什么改动的话,我还必须相应的修改文档。也就是说,这文档让我的劳动加倍了。但是,这并不是说文档是不重要的。相反,如果用源代码和说明来记录文档,就简单多了。在每一个函数的开头,都用一段注释来解释函数的功能,如何使用,需要注意的问题等等。如果是一段比较复杂的代码,需要解释你所采用的方法。没有必要采用另外一个文件来记录文档,而只用在源代码中间来写文档。这样你就能够在你需要文档的时候随时找到它们。其他的程序员也会很方便的使用你的代码。而且,不象一个专门的独立的文档那样,其他的程序员将会无意识的阅读你的文档,而不会置之不理。如果有人来问你关于某一段代码的意思的时候,你就会明白,那一段代码缺少明白的注释。所以,你可以尽快的补上它,而不会有另外一个程序员来问你同样的问题。
采用工具
在编程的工作中,你也许会常常遇到这样一些繁重的体力劳动,比如,编译一个程序,然后就是等待。或者你使用了别人写的API函数,而记住这些函数的名称和参数是一个很累的活儿。这些工作并没有什么技术可言,比如说编译程序,每天晚上都会有人把新增加的程序放到库里,然后第二天上班以后你需要来重新编译它们,往往都是一些重复的工作,但是由于程序很大,编译的过程很漫长,而你就要陷入等待状态。那么,为什么不采用工具呢?或者写一些这样的工具?我就这样做过。我写过一个程序,让它每天早上3点开始,重新编译程序,到了早上8点左右,差不多就编译完成了。然后捕获错误,如果有的话,就发电子邮件给相关的人。这样,到了上班的时间,每个人都能得到一个最新的,编译好的程序。如果代码中有错误,还能最快的得到错误报告。再比如,我需要使用别人写的API函数,当然,我不能指望每个人写的函数都采用同样的命名方法和参数定义方法,也不可能每次需要使用的时候都去查看文档,那样太浪费时间而且效率太低。我写了一个工具,让它来检查我的函数调用是否正确,参数是否正确。如果有错误,则从文档中找到可能的函数,并在错误日志中给予提示。然后我就能很快的编写代码,而不用担心函数拼写,参数调用的类型和顺序了。你也可以这么做,当下次有人来问你某个函数的名称,参数类型,参数顺序的时候,你就能够告诉他,该怎么做,用什么工具了。
可复用的代码
有一个好的比方,用来描述一个引擎。有一个不是程序员的朋友问过我一个问题,什么是程序引擎?有什么作用?为什么要用引擎?我尽量的用通俗的语言回答它,一个程序引擎就像一个汽车的引擎。没有它,汽车不能启动,但是,同时,一个没有轮胎的引擎,也是没有用处的。
我想,这是一个好的例子。这个朋友说,当你的引擎不能用的时候,你可以换一个。如果传动带坏了,你可以换一个新的,同时把引擎的性能调整到最好。同样,一个引擎有相同的部分,比如,传动装置,等等。它们对于一个引擎是重要的,如果某一个部分坏了,你不能不拆开引擎来更换它。
然后我的朋友总结道:如果你从头来写一个程序引擎,你就不得不从头来写所有的传动带,所有的零件。如果你能用一些以前用过的部分,你就能简单的把它们拼装到一起而不用重新写了。
没错。他并不懂得如何去写程序,但是他道出了编程的真谛。这也是一个普通的程序员和一个高级程序员的区别。采用可复用的代码,让工作变得简单。
写通用的代码的关键是,不要让你的子程序变长,不要超过一屏。关键要把你要做的事情分解开,变成小巧的,可以复用的函数,要么完成一个功能,要么调用另外的函数来完成一个完整的功能。
比如,VectorAdd()可能包含了一段代码把两个vectors的元素合并到一起,而SceneDisplay可能包含了调用PrepRender(), Render2dObjects(), Rende
rHud()的代码。每一个函数可能都只有几行。
当你把代码分解成小的部分的时候,你将能够集中注意力到一些在其他地方可以复用的功能上。在前一个例子中,RenderHud()和RenderDebugText()可能共享了同样的一段函数调用,因为它们都是在屏幕上描画一些对象。
的,哪些是错误的。有一些编程的方法是我从实际工作中总结而来的,也确实感到它们能够帮助我养成良好的编程习惯。其中最重要的一件事情就是记住,当你看到这些经验的时候,不要认为他们太简单和基础,觉得一种方法是不值得学习的。很多程序员认为检查错误和写程序注释是浪费时间。而我认为,这些经验能够帮助我们节省时间和精力。在实践过程中,我了解到,我能够更快的编写代码,代码也更加的有效率。
做最坏的打算
假设你是一个超级程序员,你的代码永远都不会有错误。但是,如果你的完美的代码没有得到完美的数据,事情将会如何?你的代码假设一个指针是合法的,或者它会把一个声音文件当作一个图片来处理?基本上来说,一段代码
不能假设任何事情。C语言又一个标准的函数 assert, 它能够用来捕获错误。每次你的代码接收到用户数据,请注意要先确认数据是你所预想的。如果不是,使用assert并且打印消息来解释出现了什么错误。这是很重要的,这样你就能够让任何阅读你的程序的人了解到,什么是正确的数据,什么是错误的。百分之九十的错误都是一些简单的错误。所以,不要让这种错误影响你的程序浪费调试人员的时间,而只需要简单的在那些地方给出一个assert, 就能够避免。百分之九十的时候它能够容易的被改正。而另外百分之十的时候,它能够在变成一个大的错误之前被调试人员注意到并且改正。不论你采用哪种编程语言,你编写的第一个程序一般都是打印一条消息。把这个打印消息的功能作为你的程序中一个基本的函数,能够简单的打印任何错误。这样,程序就能分辨不明显的错误,你也能在任何错误可能出现的地方使用这个打印错误消息的函数。这样,就能够节省寻找错误的时间,从而让改正错误的时间减短。
注释
不要企图记住你的代码是用来做什么的。在你编写完一段程序几个月之后,你不会记得在编写程序的时候的想法,也不会记得什么代码是用来干什么的。所以,写注释是一个好的方法,特别是当你需要别人来阅读你的代码,或者是为了你半年之后还能记起来这段代码的目的。如果有一个同事告诉你,你的代码有一个错误,你将不得不重新检查并且改正它。如果你能够通过注释来回忆起什么代码用来做什么,你就能快一点找到并且改正错误。这个方法也是比较简单的,只需要注明你的那一段代码是做什么的,这就够了。而如果你不这么做,其他的阅读你的程序的人将看不懂它的意思,不知道变量是用来做什么的,哪些复杂的计算又是用来做什么的。如果你说明了它们的意义,就简单多了。比如,看这样的代码if "(frmp>10)", "(plist.bdown & x03)", "(plist.y > pond.y)"就比看注释要复杂的多。当你写注释的时候,你会得到两种好处。
任何人都能明白你希望一段代码去做什么,而且,如果这段代码有错误,阅读代码的人就能发现,它没有执行你在注释中希望它去做的事情,那样就能尽快的发现错误和改正它。注释是程序员最重要的工具之一。而且所有的语言都支持注释。所以,记住,要写注释。
文档
当我在写一个文档的时候,我记得我花了很多篇幅来写一段关于系统和模块的文档。这个文档是正确的,但是却是没有用的。因为,没有人读过它。很多人都忘记了还有这篇文档,而是在需要的时候来问我,让我来解释给他们。
这种方法也不错,它比查阅整个文档快多了。很少有机会有人会花上一大段时间来通读整个文档。所以说,我当时写文档的时间是浪费了。而且,如果这个系统和模块要做什么改动的话,我还必须相应的修改文档。也就是说,这文档让我的劳动加倍了。但是,这并不是说文档是不重要的。相反,如果用源代码和说明来记录文档,就简单多了。在每一个函数的开头,都用一段注释来解释函数的功能,如何使用,需要注意的问题等等。如果是一段比较复杂的代码,需要解释你所采用的方法。没有必要采用另外一个文件来记录文档,而只用在源代码中间来写文档。这样你就能够在你需要文档的时候随时找到它们。其他的程序员也会很方便的使用你的代码。而且,不象一个专门的独立的文档那样,其他的程序员将会无意识的阅读你的文档,而不会置之不理。如果有人来问你关于某一段代码的意思的时候,你就会明白,那一段代码缺少明白的注释。所以,你可以尽快的补上它,而不会有另外一个程序员来问你同样的问题。
采用工具
在编程的工作中,你也许会常常遇到这样一些繁重的体力劳动,比如,编译一个程序,然后就是等待。或者你使用了别人写的API函数,而记住这些函数的名称和参数是一个很累的活儿。这些工作并没有什么技术可言,比如说编译程序,每天晚上都会有人把新增加的程序放到库里,然后第二天上班以后你需要来重新编译它们,往往都是一些重复的工作,但是由于程序很大,编译的过程很漫长,而你就要陷入等待状态。那么,为什么不采用工具呢?或者写一些这样的工具?我就这样做过。我写过一个程序,让它每天早上3点开始,重新编译程序,到了早上8点左右,差不多就编译完成了。然后捕获错误,如果有的话,就发电子邮件给相关的人。这样,到了上班的时间,每个人都能得到一个最新的,编译好的程序。如果代码中有错误,还能最快的得到错误报告。再比如,我需要使用别人写的API函数,当然,我不能指望每个人写的函数都采用同样的命名方法和参数定义方法,也不可能每次需要使用的时候都去查看文档,那样太浪费时间而且效率太低。我写了一个工具,让它来检查我的函数调用是否正确,参数是否正确。如果有错误,则从文档中找到可能的函数,并在错误日志中给予提示。然后我就能很快的编写代码,而不用担心函数拼写,参数调用的类型和顺序了。你也可以这么做,当下次有人来问你某个函数的名称,参数类型,参数顺序的时候,你就能够告诉他,该怎么做,用什么工具了。
可复用的代码
有一个好的比方,用来描述一个引擎。有一个不是程序员的朋友问过我一个问题,什么是程序引擎?有什么作用?为什么要用引擎?我尽量的用通俗的语言回答它,一个程序引擎就像一个汽车的引擎。没有它,汽车不能启动,但是,同时,一个没有轮胎的引擎,也是没有用处的。
我想,这是一个好的例子。这个朋友说,当你的引擎不能用的时候,你可以换一个。如果传动带坏了,你可以换一个新的,同时把引擎的性能调整到最好。同样,一个引擎有相同的部分,比如,传动装置,等等。它们对于一个引擎是重要的,如果某一个部分坏了,你不能不拆开引擎来更换它。
然后我的朋友总结道:如果你从头来写一个程序引擎,你就不得不从头来写所有的传动带,所有的零件。如果你能用一些以前用过的部分,你就能简单的把它们拼装到一起而不用重新写了。
没错。他并不懂得如何去写程序,但是他道出了编程的真谛。这也是一个普通的程序员和一个高级程序员的区别。采用可复用的代码,让工作变得简单。
写通用的代码的关键是,不要让你的子程序变长,不要超过一屏。关键要把你要做的事情分解开,变成小巧的,可以复用的函数,要么完成一个功能,要么调用另外的函数来完成一个完整的功能。
比如,VectorAdd()可能包含了一段代码把两个vectors的元素合并到一起,而SceneDisplay可能包含了调用PrepRender(), Render2dObjects(), Rende
rHud()的代码。每一个函数可能都只有几行。
当你把代码分解成小的部分的时候,你将能够集中注意力到一些在其他地方可以复用的功能上。在前一个例子中,RenderHud()和RenderDebugText()可能共享了同样的一段函数调用,因为它们都是在屏幕上描画一些对象。