翻译自：CODING HORROR，版权属于：Jeff Atwood
为什么要写伪代码？
我很喜欢《代码大全》（英文名：Code Complete）这本书——他也是我强烈推荐的一本书之一——即使是在十六年之后的今天，里面的许多章节我仍然没有完全消化。
其中的一个章节描述了关于伪代码编程过程方面的内容。至少从理论上来说，这是很合理的。也就是说，在你写一个例程之前，你应该用简单明了的英语把它描述一下。那么，当我们要写一个错误处理例程的之前，就应该先这样写：
然后，当你对这个例程的功能满意之后，就要把所有的伪代码改成注释，并且添加上实际的代码，就像下面这样：
伪代码就像是编程语言中的Tang果汁——用实际代码将它水合。
但是为什么要使用伪代码呢？Steve（也就是Steven McConnell,这里是他的介绍，代码大全的作者）
- 伪代码更易于检查。你可以检查设计的细节而不必去查看源码。伪代码使得底层的设计检查更加容易，而不必去查看源码本身。
- 伪代码支持迭代细分的思想。当你从高层次的设计开始，并把这个设计提炼成伪代码，然后把伪代码写成实际的代码。这个不断细分的过程，使得你去审视一些低层次的细节。结果，你可以在高层次上发现高级的错误，中等层次上发现中级的错误，在最低层次上发现最低级的错误——当然是在它们变成问题之前或者在更细的层次上给你的工作带来影响之前。
- 伪代码更易于修改。几行的伪代码比一页的代码易于修改。你是喜欢修改设计图上的一行，还是喜欢把它钉在墙上一点一点地区寻找别的细节呢？在软件开发上这种效果虽说不像身体上的变化那么明显，但是在变化的原则上是一致的。项目成功的关键就是在最少价值阶段发现错误，这个阶段就是投入的努力最少的那个阶段。显然，在编写伪代码的阶段的投入要比编好所有代码、测试、调试这个阶段的投入小得多。早些发现错误的发生也更加具有经济效益。
- 伪代码极大减少了注释的工作。典型的编程方式是，你先写好代码，再添加上注释。在PPP中，伪代码变成了注释行，显然把这些伪代码留下是更好的选择。
- 伪代码比其他的设计文档更加易于维护。在其它的设计方式当中，设计是和代码分开的。当其中一个发生变动，两者都需要改变。在PPP中，伪代码变成了代码中的注释，只要这些注释受到了维护，那么伪代码也就是准确的。
所有以上的论据，作为McConnell的助手，我还是很难痛快地接受。每当我尝试着写伪代码的时候，都是因为觉得不切实际而马上放弃。
为什么？有两个原因：
1.Code>Pesudocode。我发现就码论码（在书写代码的时候思考代码）要容易的多，尽管我赞成用简单的话讲总体的目的书写下来——这样也便于命名，但是这太困难了。扩展例程的内部对我丝毫不起作用。试图用精确的语言去描述代码是根本不切实际的。
2.以在代码中添加注释为目的的开始是种倒退。我更喜欢无注释的书写代码，那样会使代码像人的语言那样更有表现力。但是，我的代码中也有注释，只有当我的代码无法说明的时候，我才会添加必要的注释。请注意，注释应当成为最后的依靠，而不是开始。
当然PPP只是对编程方式的一种建议，而不是完美的理想的方式。McConnell在这上面也没有提供错误的概念，他认为refactoring, TDD, design by contract,和 plain old "hacking"都是可供选择的构建代码的方式。
但是，除非是在工作面试的时候，我仍然难以把伪代码当成有用的东西。尽管那样，我还是喜欢坐在计算机前，用实际的代码来解决遇到的问题。你呢？在你的编程当中伪代码有用吗？你在写代码之前写伪代码吗？
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
