国际：编写简练代码是程序员的职业修养之本(转载)

zgc2008

我曾经接受过一个关于优秀代码标准的电话采访。当时，我脑海中闪过的第一个念头就是：可维护性。如果代码难以被其他开发人员理解，维护或是扩展，都不能称其为优秀的代码。然后，我想到另外一些标准：高效，优雅 (简练，适当运用语言结构，环境适用性) ，模块化，适当的面向对象设计，等等。

当然，能够在没发生错误和没有安全漏洞等问题的情况下运行代码，这是优秀代码理所当然拥有的特质。

在《 Code Complete 》一书中，作者 Steve McConnel 在代码的可维护性上充分地支持了我的观点：

这本书所要做的另外一件事情就是，强调代码的易读性。而在独立编写代码的背后，其实隐藏着能与其他开发者顺利沟通的深层次目标。

计算机可不管你的代码是否好懂，虽然它看起来是能读懂你的程序，事实上计算机是在二进制环境下运行程序的。而编写可读性强的语言，则有利于其他开发者读懂你的程序。所以下这些对代码的可读性有着积极的影响：

1、易于理解性

2、复查性

3、错误率

4、Debug

5、可修改性

6、开发时间 - 上述因素的总和

7、扩展质量 - 上述因素的总和

编写可读性强的代码，事实上也不会花费更多的时间，至少在开发的最后阶段是这样的。可读性强的代码能让你更容易看懂自己写了些什么，这也是为什么要如此做的重要原因。而且，我们在查看代码时往往会顺便检查代码，这样也有利于纠正错误。可读性强的代码在阅读时会被修正，也更容易使别人把你的代码应用到类似的程序中。

……

编写可读性强的代码是开发过程中的不二选择。倾向花费大量时间写代码，却忽视阅读上的便利性，本身是一种错误的体制。开发人员应该尽力编写优秀的代码，因为这是一劳永逸这事，也不必因为糟糕的代码而花费更多精力。

另外，来自 MSDN END BRACKET 栏目的作者 Paul DiLascia ，也列出了优秀代码应有的物质：

不管你用什么语言进行开发，所有的优秀代码都会展示出共有的经典品质：简练，易于理解，模块化，层次性，设计良好，高效，优雅，并且清晰。

简练。这意味着能用五行代码解决的问题，绝不用十行代码。这也意味着，必须花费更多的精力来保证代码的简练，而不是生产令人费解的代码；这还意味着，你所厌恶的事情，是连篇累牍的开放性代码和函数。简练——即结构好，可执行，设计优秀——可以让你的代码更易于理解，也减少了错误的发生。

可读性强。正如其字，这说明你的代码应该更能让其他人看懂。要做到可读性强，就得多写注释，符合大众习惯，不要自作聪明地命名变量，比如说，用 taxrate 代替 rt 。

模块化。这意味，你得像宇宙的构成一样来开发程序。世界是由分子构成的，而这些分子又同原子，电子，核子，夸克，和连线 (如果你相信的话) 组成。类似的，优秀的程序也是由小模块建立成大的系统，而这些小模块又由更小的部分来组成。你完全可以只使用移动，插入和删除三个简单的应用，来编写一个文本编辑器。就像原子的构成方式一样，软件的组件也应该具有复用性。

层次性。程序得像蛋糕内部一样层次分明。应用运行在框架之上，框架运行在系统之上，而系统又运行在硬件之上。就算是应用程序的内部，也应该有层次。高级层访问低级层，而且事件正好相反(向下访问，向上返回) ，低级层不应该知道高级层在干些什么。事件/反馈的基本特性，就是向上发出无指向性通知。如果你的文档直接访问了框架，那可就有危险了。模块和层次由 API 来定义，这样就限定了各自的运行范围。因此，设计就变得由为重要了。

设计良好。在开发程序之前，要先花些时间来设计你的程序，因为思考的代价要小于调试。优秀的开发准则就是，花一半时间来设计。你得写一份功能说明 (这个程序是用来干嘛的) 和一个深层蓝图，而 API 的功能也应该整理成文。

高效。程序不但要运行快，而且要节省资源，它不能牵扯到文档，数据连接等等。程序只做它该做的事，不能胡乱地装载和撤销线程。在运行层上，你可以在测试之后才优化程序；但是在高级层，你必须先计划好执行过程。如果设计中要求服务器有大批量的延迟，最好用一个 DOG ( Data Output Gate ，数据输出门)。

优雅。和漂亮是一个概念，它难以描述却显而易见。优雅综合了简练，高效和简明等概念，同时还能让人感受到高贵的气质。举个例子，优雅就是使用表格，或者是用递归来编写程序：

{

    return n==0 ? 1 : n * factorial(n-1);

}

清晰。清晰是优秀代码的基本，也是其他要素的品质保证。相对于普通机械，计算机建立更为复杂的系统的能力要强得多。对于编程来说，最基础的挑战就是减少复杂度。简单、可读性强、模块化、层次、设计良好、高效、优雅，都是久经考验达成简练代码的方法，这些可以有效地减少代码的复杂度。

清晰的代码，良好的设计，明确的目标，你必须真正地了解到自己在每个步骤所要做的事情，否则就会一事无成。差劲的程序，往往不是因为编程技术水平的问题，而是因为没有一个明确的目标。所以，设计是开发的关键，能让保持自己的目标。如果不能写出设计计划，不能向其他人解释开发目标，其实说明你连自己在做什么都不知道。

什么才是“优秀代码”最重要的特点？显然，就像软件工程里所面临的问题一样，是代码的平衡性。编写代码时，我们总是会努力保证复杂与简练之间的平衡：选择折衷的方式来编写代码，通过不断地测试来达成我们所期望的目标。

这样，优秀的代码才会完美地达成上文中所提到的所有特质。下次写程序或是看别人的代码时，好好地想想这些问题吧。

作者介绍

Eran Kampf 有 8 年多的软件开发和研究经验。曾经以高级软件开发者的身份工作于 IDF 的 elite geospatial-intelligence 部门。现在在 SAP 担任 R&D 工程师，在 SAP 和 Microsoft 合作开发的项目中工作。

链接：http://www.ekampf.com/blog/2008/06/26/HowDoYouDefineQuotGoodCodequot.aspx

游戏之家站长

你说的是商业游戏还是业余游戏？

zgc2008

我只是转载 顺便灌水 楼上可以无视了

游戏之家站长

我只知道，做业余游戏随意性很大，不想做的时候就停止，至于做的好不好都不会拿去卖，只是娱乐。
维护代码吗？ 那是大工程，我的代码就几千行，没那么复杂，以前有人说我的游戏有BUG，那不是BUG，
是我根本就没设计那个功能，例如敌人的子弹穿墙，我没设计敌人的子弹判断障碍物，只要游戏可以正常
运行，不死机，不出错就是正常游戏，至于那些功能，以后会完善。

ricohcanon

游戏之家站长: Re:国际：编写简练代码是程序员的职业修养之本(转载)

我只知道，做业余游戏随意性很大，不想做的时候就停止，至于做的好不好都不会拿去卖，只是娱乐。
维护代码...

嗯，理解。我也是这样，有一些逻辑纠错功能压根就没设计（懒得设计），用户瞎操作（不按套路走）当然会出错啦，哈哈，反正是白用，又不收费，挑啥挑啊，爱用不用，又不求着你用，切～～～ [em17] [em20] [em19]

zgc2008

ricohcanon: Re: Re:国际：编写简练代码是程序员的职业修养之本(转载)


嗯，理解。我也是这样，有一些逻辑纠错功能压根就没设计（懒得设计），用户瞎操作（不按套路走）当然会出...

是啊 幸好是VB6 如果换成C++这中垃圾语言,还不知道要死多少次机才能打完一个游戏.

VB6就是好.........

游戏之家站长

ricohcanon: Re: Re:国际：编写简练代码是程序员的职业修养之本(转载)


嗯，理解。我也是这样，有一些逻辑纠错功能压根就没设计（懒得设计），用户瞎操作（不按套路走）当然会出...

是呀！ 五星勋章2里有个BSP地图是网络上找的，没做限制，有个地方是个坡会，乱冲走出墙外，不过那地方涉及不到游戏里的情节，如果非要检验地图是不是有问题，那我也没办法，但玩家对我游戏的评价还是肯定的。

还有五星勋章2里拿枪的手的位置有点偏，我想这都不影响射击的准确度。

我要是专业设计商业游戏，就不用我做地图了，也不会出那错，自己做游戏什么都要一个人，有时候管不了那么多。

游戏之家站长

zgc2008: Re: Re: Re:国际：编写简练代码是程序员的职业修养之本(转载)


是啊 幸好是VB6 如果换成C++这中垃圾语言,还不知道要死多少次机才能打完一个游戏.

VB6就是好.........

你以为用VB6不会死机？一样的，有时候很恼火，我调试游戏都是满屏幕独占模式，如果z最前面这个画面死掉了，按什么键都没用，只能RESET。
写个简单小游戏就没那个问题。
但是C++调试代码更麻烦，很多错误到游戏完成后都找不到。

zgc2008

游戏之家站长: Re: Re: Re: Re:国际：编写简练代码是程序员的职业修养之本(转载)




你以为用VB6不会死机？一样的，有时候很恼火，我调试游戏都是满屏幕独占模式，如果z最前面这个画面死...

你可以换成窗口模式撒.....当然你会告诉我,你不会这么弄的.......然后就是一大堆理由

游戏之家站长

zgc2008: Re: Re: Re: Re: Re:国际：编写简练代码是程序员的职业修养之本(转载)


你可以换成窗口模式撒.....当然你会告诉我,你不会这么弄的.......然后就是一大堆理由

从你说的话里看出你一点也不懂编程，只能抄抄别人的文章。
（1）先有窗口，才有满屏（我也可以不用窗体直接写在显存里）
（2）窗口模式MOUSE的光标在，不好调试，如果隐藏了死机更麻烦，退出游戏连WINDOWS的光标都找不到了。
（3）我说的理由都是有充足证据的，你们在纸上做游戏是不会有BUG的。
（4）没有完美的程序，路是一个脚印一个脚印走出来的。