pseudocode - 現実の世界で疑似コードをどのくらいの頻度で使用しますか?

Question

大学に戻ると、私のカリキュラムでは疑似コードの使用だけが OOP よりも多く宣伝されていました。コメント (および他の説教された「ベストプラクティス」) と同じように、私は、危機的な時期に疑似コードがしばしば無視されていることに気付きました。だから私の質問は...実際にそれを頻繁に使用しているのは誰ですか? それとも、頭の中でアルゴリズムを完全に概念化するのが本当に難しい場合にのみ使用しますか? 私は皆からの反応に興味があります.

個人的には、ほとんど難しいことだけに使っています。

score 15 · Accepted Answer

いつも使っています。設計上の決定を説明する必要があるときはいつでも、それを使用します。非技術スタッフと話して、私はそれを使用します。プログラミングだけでなく、何かがどのように行われるかを説明するためのアプリケーションがあります。

複数のプラットフォーム (この場合は Java フロントエンドと COBOL バックエンド) でチームと協力する場合、実際のコードを示すよりも、擬似コードを使用してコードの一部がどのように機能するかを説明する方がはるかに簡単です。

設計段階では、解決策とそれが実現可能かどうかを確認するのに役立つため、疑似コードは特に役立ちます。非常に洗練されたデザインを見たことがありますが、それらを実装しようとして、疑似コードを生成することさえできないことに気付きました。結局、設計者は理論的な実装について考えようとしたことがありませんでした。もし彼が彼のソリューションを表現する疑似コードを書き上げようとしていたなら、私はなぜそれが機能しないのかを理解するために 2 週間を無駄にする必要はなかったでしょう。

score 5 · Accepted Answer

コンピューターから離れているときは疑似コードを使用し、紙とペンしかありません。コンパイルできない (論文をコンパイルできない) コードの構文について心配するのはあまり意味がありません。

score 5 · Accepted Answer

最近では、重要なルーチンを作成するときに、ほとんどの場合、これを使用しています。擬似コードをコメントとして作成し、その下に同等のコードを記述できるようになるまで拡張を続けます。これにより、開発が大幅にスピードアップし、実際のコードを書く前にプロセス全体を考える必要があるため、当初は考慮されていなかったものの書き直しが必要になることが多い「コードを書くだけ」症候群が減少し、それが書かれた後のコードのドキュメント。

score 3 · Accepted Answer

私と私のチームの他の開発者は、常にそれを使用しています。メールでも、ホワイトボードでも、会話でも。疑似コードは、必要な方法で考え、プログラミングできるようにするのに役立ちます。疑似コードを本当に理解していない場合は、ほとんどすべてのプログラミング言語に追いつくことができます。それらすべての主な違いは構文であるためです。

score 2 · Accepted Answer

Steve McConnel のCode Completeの第 9 章「The Pseudocode Programming Process」では、興味深いアプローチが提案されています。数行よりも長い関数を記述する場合は、単純な擬似コードを (コメントの形式で) 使用して、関数/プロシージャに必要なものを概説します。それを実行する実際のコードを書く前に実行してください。疑似コードのコメントは、関数の本体で実際のコメントになることができます。

私はこれを、画面全体 (最大) のコードを見てすぐに理解できる以上のことを行う関数に使用する傾向があります。関数本体をコードの「段落」 (空行で区切られた意味的に関連するコードの単位) で区切ることに既に慣れている場合、これは特にうまく機能します。次に、「疑似コードコメント」は、これらの段落の「ヘッダー」のように機能します。

PS: 一部の人々は、「問題の言語をあなたよりよく知っている読者にとって理解するのが簡単ではない場合にのみ、何をコメントするべきではなく、理由をコメントするべきではない」と主張するかもしれません。私はおおむねこれに同意しますが、PPP については例外とします。コメントの存在と形式の基準は、固定的に設定されるべきではありませんが、最終的には賢明でよく考えられた常識の適用によって管理されるべきです. 主観的な「規則」に少し曲げて試してみることを拒否している場合は、一歩下がって、十分に批判的に直面していないかどうかを認識する必要があるかもしれません.

score 2 · Accepted Answer

概念を説明するときに使用します。質問に関連する詳細のみが例に含まれるように、不要な言葉を削除するのに役立ちます。

私は StackOverflow でかなりの量を使用しています。

score 2 · Accepted Answer

複雑な問題を解決する場合は、それをよく使用しますが、コメントとして使用します。たとえば、手順をスタブ化し、実行する必要があると思われる各ステップを挿入します。次にコードを書きながら、コメントを残します。それは、私が何をしようとしていたかを示しています。

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;

score 2 · Accepted Answer

プログラムを書く前に、プログラムの疑似コードを書く必要があったことは一度もありません。

ただし、コードを書いた後に疑似コードを書かなければならないこともありました。これは通常、プログラムの高レベルの実装を記述して、誰かが新しいコードを短時間で理解できるようにするときに発生します。また、「高レベルの実装」とは、疑似コードの 1 行で C# の 50 行ほどが記述されていることを意味します。たとえば、次のようになります。

Core は一連の XML ファイルをフォルダーにダンプし、process.exe を実行します。
  いくつかのコマンドライン パラメータで実行可能です。

process.exe は各ファイルを読み取ります
    各ファイルは行ごとに読み取られます
    データベースに保存されたファイルからユニークな単語を抽出
    処理が終了するとファイルは削除されます

この種の疑似コードは、約 1000 行のコードを記述するのに十分であり、プログラムが実際に何を行っているかを初心者に正確に伝えるのに十分です。

問題を解決する方法がわからない場合は、モジュールがどのように相互作用するかを明確に把握するために、ホワイトボードにモジュールを非常に高いレベルで描画し、データベーススキーマのプロトタイプを描画し、データ構造（特にツリー、グラフ、配列など）を調べて、それをトラバースして処理する方法などを適切に把握します。

score 2 · Accepted Answer

学校で教えられているように、私は疑似コードを使用していません。

ロジックが十分に複雑な場合は、アルゴリズムの英語の説明を使用します。それらは「コメント」と呼ばれます。;-)

人に説明するときや紙に書き出すときは、できるだけ図を使います。

score 1 · Accepted Answer

ほとんどの場合、非常に複雑なコードを作成するため、またはシステムを理解している他の開発者または非開発者にコードを説明する場合に使用します。

上記のことをしようとすると、フロー図またはUMLタイプの図も...

score 1 · Accepted Answer

私はそれを使用したり使用したりしたことはありません。

複雑なことをする必要があるときは、常に実際の言語でプロトタイプを作成しようとします。通常は、最初に単体テストを作成して、コードが何をする必要があるかを把握します。

score 1 · Accepted Answer

私は通常、混乱を招く可能性のあるネストされた複数の if else ステートメントを開発するときに使用します。

この方法では、すでに完了しているため、戻って文書化する必要はありません。

score 1 · Accepted Answer

めったにありませんが、メソッドの本体を記述する前にメソッドをドキュメント化することがよくあります。

ただし、問題へのアプローチ方法について他の開発者を支援している場合は、疑似コードのソリューションを記載したメールをよく書きます。

score 1 · Accepted Answer

私は疑似コードをまったく使用しません。私は疑似コードよりも C スタイル言語の構文に慣れています。

私が設計目的で頻繁に行っているのは、本質的に機能分解スタイルのコーディングです。

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

理想的な世界では、メソッドがますます自明になるにつれて、これは最終的に機能するコードに変わります。ただし、実際には、設計のリファクタリングと再考が非常に多くあります。

信じられないほど複雑でコーディングが難しく、UML やその他のモデリング手法を使用してもうまく解決できないアルゴリズムに遭遇することはめったにないため、これで十分に機能することがわかります。

pseudocode - 現実の世界で疑似コードをどのくらいの頻度で使用しますか?

14 に答える 14

Related

Reference