Question

回到大学时，我的课程中只使用伪代码而不是OOP。就像评论（以及其他传播的“最佳实践”）一样，我发现在关键时刻，伪代码经常被忽略。所以我的问题是......谁在很多时候实际使用它？或者，当一个算法真的难以完全概念化时，你是否只使用它？我对每个人的回答很感兴趣：在初期的初级开发人员和那些在打卡时代回来的灰白色的兽医。

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

Answer 1

我一直都在使用它。每当我必须解释设计决定时，我都会使用它。与非技术人员交谈，我会用它。它不仅适用于编程，也适用于解释如何完成任务。

在多个平台上使用团队（在这种情况下，使用COBOL后端的Java前端），使用伪代码解释一些代码的工作方式比显示实际代码要容易得多。

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

Answer 2

我在离开电脑时使用伪代码只有纸和笔。担心无法编译的代码语法（无法编译纸张）没有多大意义。

Answer 3

我现在几乎总是在创建任何非平凡的例程时使用它。我创建伪代码作为注释，并继续扩展它，直到我到达我可以写下面的等效代码。我发现这显着加快了开发速度，减少了“只写代码”综合症，这种综合症往往需要重写原本并不被认为是强制你在编写实际代码之前考虑整个过程的事情，并且是一个很好的基础。编写后的代码文档。

Answer 4

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

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章“伪编码编程过程”中提出了一种有趣的方法：当编写一个长于几行的函数时，使用简单的伪代码（以注释的形式）来概述什么在编写执行它的实际代码之前，函数/过程需要做。然后伪代码注释可以成为函数体中的实际注释。

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

PS：有些人可能认为“你不应该评论什么，而是为什么，只有当对于比你更了解所讨论的语言的读者而言理解这一点并不容易”。我普遍同意这一点，但我确实对PPP做了例外。评论的存在和形式的标准不应该是一成不变的，但最终还是由wise, well-thought application of common sense控制。如果你发现自己只是为了它而拒绝尝试一种主观的“规则”，你可能需要退后一步，意识到如果你没有足够严格地面对它。

Answer 10

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

我还试图在上面做图表或uml类型图...

Answer 11

我通常在开发嵌套的多个if else语句时使用它，这可能会令人困惑。

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

Answer 12

相当罕见，虽然我经常在写一个方法之前记录一个方法。

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

Answer 13

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

出于设计目的，我经常做的事实上是编码的功能分解方式。

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

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

我们发现这种方法运行得很好，因为我们很少遇到两种算法：使用UML或其他建模技术难以编码且难以编码。

Answer 14

我从不使用或使用它。

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

你经常在现实世界中使用伪代码吗？

14 个答案: