9

回到大学，在我的课程中，只有伪代码的使用比 OOP 得到了更多的宣传。就像评论（和其他宣扬的“最佳实践”）一样，我发现在关键时刻伪代码经常被忽视。所以我的问题是......谁实际上经常使用它？还是仅在您很难完全在脑海中概念化算法时才使用它？我对每个人的回应都很感兴趣：耳后湿透的初级开发人员到打孔卡时代就在身边的头发花白的老兵。

就我个人而言，我主要只将它用于困难的事情。

4

14 回答 14

15

我用它所有的时间。每当我必须解释设计决策时，我都会使用它。与非技术人员交谈，我会使用它。它不仅适用于编程，还适用于解释任何事情是如何完成的。

与在多个平台上的团队合作（在这种情况下，Java 前端和 COBOL 后端）使用伪代码解释一段代码的工作原理比显示真实代码要容易得多。

在设计阶段，伪代码特别有用，因为它可以帮助您了解解决方案以及它是否可行。我见过一些看起来非常优雅的设计，只是为了尝试实现它们并意识到我什至无法生成伪代码。事实证明，设计师从未尝试过思考理论上的实现。如果他试图编写一些伪代码来代表他的解决方案，我就不必浪费 2 周的时间来弄清楚为什么我不能让它工作。

于 2008-12-11T18:59:57.500 回答
5

我在远离计算机并且只有纸和笔时使用伪代码。担心无法编译的代码（无法编译论文）的语法没有多大意义。

于 2008-12-11T18:58:47.610 回答
5

我现在几乎总是在创建任何重要的例程时使用它。我将伪代码创建为注释，并继续扩展它，直到我可以在它下面编写等效代码为止。我发现这显着加快了开发速度，减少了“只写代码”综合症，这种综合症通常需要重写最初没有考虑过的事情，因为它迫使您在编写实际代码之前仔细考虑整个过程，并作为良好的基础编写后的代码文档。

于 2008-12-11T19:02:51.737 回答
3

我和我团队中的其他开发人员一直在使用它。在电子邮件、白板或只是在会议中。伪代码可以帮助您以您需要的方式思考，以便能够编程。如果您真的不了解伪代码，您几乎可以掌握任何编程语言，因为它们之间的主要区别在于语法。

于 2008-12-11T19:18:14.467 回答
2

如果我正在解决一些复杂的问题，我会经常使用它，但我会将它用作注释。例如，我将删除程序，并放入我认为需要执行的每个步骤。当我写代码时，我会留下评论：它说明了我想要做什么。

procedure GetTextFromValidIndex (input int indexValue, output string textValue)
// initialize
// check to see if indexValue is within the acceptable range
//    get min, max from db
//    if indexValuenot between min and max
//       then return with an error
// find corresponding text in db based on indexValue
// return textValue
   return "Not Written";
end procedure;
于 2008-12-11T19:05:26.117 回答
2

在编写程序之前，我从来没有，甚至一次都不需要编写程序的伪代码。

但是，有时我不得不在编写代码之后编写伪代码，这通常发生在我试图描述程序的高级实现以使某人在短时间内掌握新代码的速度时。“高级实现”是指一行伪代码描述了大约 50 行 C#，例如：

Core 将一堆 XML 文件转储到一个文件夹并运行 process.exe
  带有一些命令行参数的可执行文件。

process.exe 读取每个文件
    每个文件逐行读取
    从存储在数据库中的文件中提取唯一词
    文件在完成处理后被删除

这种伪代码足以描述大约 1000 行代码，并且足以准确地告知新手程序实际在做什么。

在很多情况下，当我不知道如何解决问题时，我实际上发现自己在白板上以非常高级的术语绘制我的模块，以清楚地了解它们如何交互，绘制数据库模式的原型，绘制一个数据结构（尤其是树、图、数组等），以便很好地处理如何遍历和处理它等。

于 2008-12-11T19:11:11.347 回答
2

我在解释概念时使用它。它有助于删除不必要的语言部分，以便示例仅包含与所问问题相关的细节。

我在 StackOverflow 上大量使用它。

于 2008-12-11T19:22:24.210 回答
2

我不使用学校教的伪代码，并且很长时间没有使用。

当逻辑足够复杂时，我会使用算法的英文描述；它们被称为“评论”。;-)

在向他人解释事情或在纸上解决问题时，我尽可能使用图表 - 越简单越好

于 2008-12-11T19:52:31.043 回答
2

Steve McConnel 的Code Complete在其第 9 章“伪代码编程过程”中提出了一个有趣的方法：当编写一个超过几行的函数时，使用简单的伪代码（以注释的形式）来概述函数/过程需要什么在编写执行它的实际代码之前做。然后伪代码注释可以成为函数体中的实际注释。

我倾向于将它用于任何功能，这些功能超出了通过查看一屏（最大）代码可以快速理解的功能。如果您已经习惯于在代码“段落”中分隔函数体，它会特别有效 - 由空行分隔的语义相关代码单元。然后“伪代码注释”就像这些段落的“标题”一样工作。

PS：有些人可能会争辩说“你不应该评论什么，而是为什么，只有当一个比你更了解所讨论语言的读者理解并不是一件容易的事时”。我大体上同意这一点，但我确实为 PPP 开了一个例外。评论的存在和形式的标准不应该是一成不变的，但最终还是要以明智、深思熟虑的常识应用为准。如果你发现自己拒绝仅仅为了某个主观的“规则”而尝试稍微弯曲，你可能需要退后一步，意识到你是否没有足够批判地面对它。

于 2011-08-31T02:33:59.543 回答
1

主要用于编写非常复杂的代码，或者向其他开发人员或了解系统的非开发人员解释代码时。

在尝试执行上述操作时，我还会使用流程图或 uml 类型图...

于 2008-12-11T19:00:53.893 回答
1

我通常在开发多个嵌套的 if else 语句时使用它，这可能会造成混淆。

这样我就不需要回去记录它，因为它已经完成了。

于 2008-12-11T19:02:29.287 回答
1

很少见，尽管我经常在编写方法主体之前记录一个方法。

但是，如果我正在帮助其他开发人员解决问题，我会经常写一封带有伪代码解决方案的电子邮件。

于 2008-12-11T19:02:38.960 回答
1

我根本不使用伪代码。我对 C 风格语言的语法比对伪代码更舒服。

出于设计目的，我经常做的事情本质上是一种功能分解的编码风格。

public void doBigJob( params )
{
    doTask1( params);
    doTask2( params);
    doTask3( params);
}
private void doTask1( params)
{
    doSubTask1_1(params);
    ...
}

在理想世界中，随着方法变得越来越琐碎，最终会变成工作代码。然而，在现实生活中，有大量的重构和重新思考设计。

我们发现这很有效，因为我们很少遇到同时具备以下两种算法的算法：极其复杂且难以编码，并且使用 UML 或其他建模技术无法更好地解决。

于 2008-12-11T19:03:37.023 回答
1

我从未使用或使用过它。

当我需要做一些复杂的事情时，我总是尝试用真实的语言进行原型设计，通常首先编写单元测试来弄清楚代码需要做什么。

于 2008-12-11T19:14:23.413 回答