フローチャートの代わりに擬似コードを使用するのはいつですか？

Fl owchartsと疑似コードは同じレベルの表現力を持っていることがよくありますが、線形化が異なります。擬似コードは線形（つまり、命令を含む一連の行）ですが、フローチャートは線形ではありません。したがって、フローチャートはより高い抽象化レベルであり、擬似コードを作成する前や文書化に使用されます。

フローチャートには、擬似コードに比べて2つの大きな利点があります。1つはグラフィカルです。技術者以外の多くの人々は、構造化されたテキストを強く恐れていますが、グラフィックの説明を恐れていないので、フローチャートは彼らに非常に適しています。第二に、フローチャートは、分岐ではなく実行のメインラインを表示するなど、メタ考慮事項を表現するのにはるかに優れています。

質問の詳細：

1. 非常に複雑な場合問題は、最初にフローチャートを使用し、次に擬似コードを使用することです。十分に安全であると感じる場合は、どちらもオプションです。
2. はい、擬似コードには、実際のコードとマージできるという利点があります。たとえば、Steve McConnellは、最初に擬似コードでメソッドを記述し、次にその擬似コードをコメントとしてコードに残すことを強くお勧めします。
3. 設計中にフローチャートを作成する必要があると、問題のパーティションが不十分であると常に感じていました。重要なフローチャートは複雑なロジックを示しており、多大なコストをかけて回避する必要があります。

コメント

• フローチャートも優れた方法です。すべての決定ポイントが、最も一般的なパスだけでなく、あまり一般的でないパスのアクションも定義していることを確認します。これにより、承認が拒否された場合や注文がキャンセルされた場合の対処方法を確実に把握できます。エッジケースでは、テストでバグが見つかったときに、QA中にバグを忘れたり、急いで実行したりするため、バグが増えることがよくあります。

擬似コードについて

正直なところ、私は擬似コードをあまり使用しません。通常、コードを書くだけの方が速いので、私のコード、それは実際のコードです。疑似コードが役立つ場合もありますが、あなたは一般的に非常に複雑なものに取り組んでいて、メソッドなどの構造を分解しようとしています。そのような場合、IDEでコメントを使用して構造をレイアウトします。うまくいくまで、コメントに実際のコードを記述します。これは、いくつかのことを行うのに役立ちます。

• 実装した領域と実装していない領域を確認できます。コメントを読んで、そこに明らかなギャップがあることを確認します。
• 実際のコードを入力すると、自分が何をしているのかを英語で説明するコメントがあります（複雑な場合はおそらく必要になります）。最初に擬似コードを書く必要があります。

フローチャートについて

通常、コードは大幅に変更されるため、より大規模でシステム全体のアーキテクチャを除いて、フローチャートは役に立ちません。デザインまたはドキュメント。そのような場合は、図をホワイトボードに貼り付けて、物事の要点を把握したり、チームの他の誰かに見せたりします。理解に役立つフローチャートが本当に必要でない限り、ソフトウェアを「実行」する必要はありません。正しい。現在、コード自体からフローチャートを生成する IDE用プラグインや、クラス図など（およびその逆 `）。真剣に正確なフローチャートを実行する必要がある唯一のリアルタイムは、アーキテクチャ全体と物事が頭の中でどのように機能するかを一度に維持できず、ねじれをキャッチするために視覚的な何かを通して話す必要がある場合です。

一般的に、個人プロジェクトに取り組んでいる間はフローチャートを作成しません（プロジェクトはそれほど大きくないため）。ほとんどの入力、出力、プロセスは明確です。

ただし、さまざまな入力ソースを使用して複雑な大規模プロジェクトで作業を開始するため、フラットファイル、データベース、手動インターフェイスなどのフローチャートが便利です。

お勧めします疑似コードとUMLダイグラムを書くと、これらのツールはより良いクラスやメソッドなどを思い付くのに役立ちます。疑似コードを書いているときに、プログラムを解決するためのさまざまで効率的な方法が見つかることがあります。

擬似コードは、少なくともコードの基本を理解している人にアイデアをすばやく表現するためのものです。フローチャートは、他のすべての人のためにきれいな絵を描くことです。同じことを理解するために。

フローチャートは、多くの異なる人々がそのドキュメントとフローチャートを使用する方が簡単であるため、ドキュメントの目的でよく使用されます。非プログラマー向けの擬似コードよりも従います。自分で作業しているプロジェクトでは、必要なのはテキストエディタだけなので、擬似コードを使用する方がはるかに便利で、作成がはるかに簡単なので、問題ありません。

フローチャートは高レベルの抽象化であり、どのように進めるかを計画できます。たとえば、

if x dies y wins

クラスやメソッド、疑似コードの観点からプログラムをどのように設計しているかに依存する必要はありません。より低いレベルの抽象化を提供します（実際には異なりますが）

if（isdead（s））y.win（）

これで、使用している言語に基づいて疑似コードを実際のプログラムに変換できるようになりました。

ゲームの場合、最初にフローチャートを使用してから設計することをお勧めします。クラスとメソッド、擬似コードを記述し、最後にそれをプログラムに変換します

私はひどいですd作成しているコードの性質を考慮してください。場合：

1. 高度に反復的/再帰的
2. 複雑な方法で分岐
3. 表現したいいくつかのシステムに実装されている

最初の2つのケースでは、擬似コードは全体像の図よりも徐々に読みにくくなります。一方、ほとんど線形のコードは、信じられないほど退屈な図を作成します。これは、プロセスを爆破するため、実際にはプロセスを理解しにくくします。

3番目のケースでは、フローチャートは、システムの境界を越えて、プロセス全体を表します。

1. 使いやすいものを使用する必要があります。そうは言っても、最近のプログラム制御をスケッチするためにフローチャートはあまり使用されていないというのが私の印象です。一つには、それらは通常、擬似コードと比較して構造化されていません。アーキテクチャをはるかに高いレベルで記述するために、UMLのようなクラス依存関係図を使用するのがより一般的です。また、アプリケーションにステートマシンがある場合は、（フローチャートのような）ステートマシン図を描くことが不可欠です。
2. ここでは正しいと思います。作業の1つの方法は、最初にソースファイルにコメントとして擬似コードを書き出し、それらの間に実際の実装行を挿入することです。
3. 繰り返しになりますが、快適に感じるものは何でも使用してください。 「わからない場合は、両方を試してみてください。あなたの練習は、あなたにとって最も役立つものにすぐに収束すると思います。特に複雑な実行順序を解こうとしない限り、フローチャートは個人的には役に立ちません。」 li>

Javaを記述できるのになぜ擬似コードを書くのか？私はJava、優れたIDE、そしてJavadocは、プログラミングの問題を把握する最も簡単な方法です。少なくともオブジェクト指向の問題です。 （そして、アーケードゲームはOOである必要があります。）この言語は、このためにゼロから設計されました。そのシンプルで簡単です。 （多分、多くの目的には単純すぎますが、これについて私が見た中で最高のものです。）Javadocのハイパーテキスト、およびIDEを介したコード自体のハイパーテキストは、想像以上に理解しやすい「図」になります。大きな紙。Javaコードは他の疑似コードと同じくらい単純で、かなり厳密です。「図」と「疑似」コードを取得すると、プログラムが実際に実行されます！

コメント

• javaなどは長く巻かれる可能性があります。” public static void main .. “または” system.out.println “またはキャメルバック表記の長い識別子、長い間そこに巻かれています。 2bをキャッチしました。そして、ライブラリの呼び出しには時間がかかる可能性があります。10年前にファイルを開いたのを覚えています。 new BufferedReader（new InputStreamReader（System.in））;のようなもの mkyongが簡単になりました。com / java / … しかし、実際には、想像できるほど簡潔な疑似コードとは異なり、呼び出すライブラリは長く曲がりくねっています。
• また、Javaまたは任意の言語では、コンパイル時にエラーが発生します。擬似コードではそのどれも。気を散らすことなくデザインに集中できます。擬似コードは’心から離れているため、擬似コードが頭に浮かぶため、疑似コードに関するコメントははるかに簡潔になります。 ‘ 1つの言語だけで考えることに制限されることはなく、’この他の言語を使用することがあります。 ‘作成するのが速くて苦痛が少なく（コンパイルは不要です。非常に流暢な場合でもコンパイルエラーが発生します）、作成時間が短いため、再設計が容易になります。
• @barlop：それは私にとってはうまくいきますが、すべての人にとってはうまくいくとは限りません。多くのコード（” BufferedReader “など）は、必要になるまで、または自分が必要かどうかを知る必要があるまで、クラスから除外します。それを機能させることができます。私が持っていても、’は、全体を考えるときに見る必要のない’クラスの邪魔にならないようにうまく隠されています。設計。コンパイラエラーは簡単に修正でき、’インスタンスを取得することさえできないポイントで間違ったクラスを使用するなどの主要な設計上の欠陥を防ぐことができます。正しいクラス。確かに、私は “この方法でのみ設計された”ソフトウェアを持っています Javaで記述されていますが、OPはJavaを使用しています。
• ファイルを開きたいとすると、openfile（ c：\ blah \ file “）はJavaよりも短いですか？または、その印刷” dfdfd “はJavaよりも短いですか？ ‘疑似コードと複数のクラスのページを（まだ）行ったことがありません。一部’ cos私は’年齢で大きなプログラムを作成していませんb）一部’ cos ‘そうは思いませんが、’疑似コードを記述して、それを実装すると思います。他の擬似コードがある場合は、より高いレベルになります。コンストラクターを含むすべてのクラスとメソッドのリストがあるかもしれません。したがって、どのクラスが何であり、そのインスタンスを取得できるかがわかります。
• したがって、’間違ったクラスを使用する状況にはなりません。しかし、とにかく、それが私のプログラムである場合、’は、私のメモにどのクラスが何であるかを書き留めています。クラスはきれいです。高いレベル。 ‘覚えていない場合は、’というメモがあります。そして、擬似コードはすべて1つの意味に関するものなので、クラスblahのインスタンスを作成するつもりで、blehを記述した場合、’は単なる書き込みのタイプミスですが、’デザインの妨げにはなりません。 （’自分で’を書いている場合は、意味がわかり、何とかして使用しました）。

ifステートメントに本当に混乱していて、理解しようとしている場合は、フローチャートを使用できます。それ。または、ループを理解しようとしている場合は、カウンターの効果を確認してください。学習している場合は、非常に役立ちます。

「簡単なステートメントをボックスに入れる必要があります。プログラムが非常に直線的で、ループとifが些細なものである場合、それは役に立たないと思います。

擬似コードは、プログラムの設計に役立ちます。構文を正しく理解する必要がなく、一部の言語に伴う煩わしさもありません。記述が速いという事実により、再設計も容易になります。コード。そして、あなたはあなたの心が望むように簡潔にすることができます、それは書くのが楽しいです、それを機能させるための精神的な努力を必要としません（デバッグがないかはるかに少ないので）、そして全体像とデザインに集中するより多くの能力。

だから、あなた自身にとって便利です。

他の人とのコミュニケーションにも使用できます。