您在现实世界中多久使用一次伪代码？

Question

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

就我个人而言，我主要只用它来处理困难的事情。

Answer 1

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

与多个平台上的团队合作（在本例中为 Java 前端和 COBOL 后端），使用伪代码解释一些代码的工作原理比显示真实代码要容易得多。

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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;

Answer 6

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

然而，有时我不得不在编写代码之后编写伪代码，这通常发生在我试图描述程序的高级实现以便让某人加快使用新代码的速度时。时间很短。 我所说的“高级实现”是指一行伪代码描述了 50 行左右的 C#，例如：

Core dumps a bunch of XML files to a folder and runs the process.exe
  executable with a few commandline parameters.

The process.exe reads each file
    Each file is read line by line
    Unique words are pulled out of the file stored in a database
    File is deleted when its finished processing

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

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

Answer 7

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

我在 StackOverflow 上大量使用它。

Answer 8

我不使用学校教授的伪代码，而且已经很长时间没有使用了。

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

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

Answer 9

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

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

PS：有些人可能会说“你不应该评论什么，而应该评论为什么，并且只有当对于比你更了解所讨论的语言的读者来说理解起来并不简单时”。 我基本上同意这一点，但我对 PPP 做了例外。 评论的存在和形式的标准不应一成不变，而最终应受

Answer 10

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

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

Answer 11

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

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

Answer 12

尽管我经常在编写方法主体之前记录方法，但这种情况相当罕见。

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

Answer 13

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

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

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

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

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

Answer 14

我从来没有用过或者用过它。

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