フローチャートの代わりに疑似コードをいつ使用しますか？

私はプログラミングのさまざまな技法を使っている学生で、疑似コードとフローチャートに出くわしました。これらは両方とも、実際にプログラミングする前に問題を検討するために使用されることを知っていますが、これについていくつか質問があります。

1. いつ計画を立てるために疑似コードを使用し、いつフローチャートを使用しますか？または、実際にプログラミングする前に両方を行う方が良いでしょう。それは私の次のプロジェクトなので、特に、JAVAの小さなアーケードゲームに適しています。
2. 疑似コードがフローチャートではなく実際のコードに非常に似ていることに気づきました。本質的にプログラムに疑似コードをコピー/貼り付けするので、これは疑似コーディングをより良くしますか（もちろん、言語に合わせて変更する必要があります。その部分は理解しています）。
3. プログラミング中にこれらの両方を使用することは現実的ですか？特に前述の同じゲーム。ありがとう。

フローチャートと疑似コードは多くの場合、同じレベルの表現力を持っていますが、線形化が異なります。疑似コードは線形（つまり、命令を含む一連の行）ですが、フローチャートはそうではありません。したがって、フローチャートはより高い抽象化レベルであり、疑似コードを記述する前またはドキュメントに使用されます。

私の意見では、フローチャートには疑似コードよりも2つの強力な利点があります。多くの非技術者は、構造化されたテキストに強い恐怖を持っていますが、グラフィカルな説明には恐れていないため、フローチャートを使用する方がずっと快適です。第二に、フローチャートは、ブランチではなく実行のメインラインを示すなどのメタ考察を表現するのにはるかに優れています。

あなたの質問の詳細：

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

疑似コードについて

正直なところ、私は疑似コードをあまり使用していません。通常、コードを記述するだけの方が高速であるため、コードを使い終えると実際のコードになります。疑似コードが役立つ場合もありますが、通常は非常に複雑なものに取り組んでいて、メソッドや何かの構造を破壊しようとしています。このような場合、IDEでコメントを使用して、問題がなくなるまで構造をレイアウトします。次に、コメントに実際のコードを記述します。これは私がいくつかのことをするのに役立ちます：

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

フローチャートについて

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

一般に、個人プロジェクト（プロジェクトはそれほど大きくないため）で作業している間はフローチャートを記述せず、ほとんどの入力、出力、およびプロセスは明確です。

しかし、入力ソースが異なる複雑な大規模プロジェクトで作業を開始するときは、フラットファイル、データベース、手動インターフェースなどのフローチャートが便利です。

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

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

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

フローチャートは高度な抽象化で、物事の進め方を計画できます。たとえば、

xが死んだ場合yが勝利

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

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

したがって、疑似コードは、使用している言語に基づいて実際のプログラムに変換できます。

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

私はあなたが書いているコードの性質を考慮します。もしそれが：

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

最初の2つのケースでは、大きな画像の図よりも疑似コードが次第に読みにくくなります。一方、ほとんど線形であるコードは、非常に退屈な図を作成します。これにより、プロセスが爆破されるため、プロセスを実際に理解することが難しくなります。

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

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

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

ifステートメントによって本当に混乱し、それを理解しようとしている場合は、フローチャートを使用できます。または、ループを理解しようとしている場合は、カウンターの効果を確認してください。あなたが学んでいるなら、それは多くの助けになるでしょう。

それはあなたが簡単なステートメントをボックスに入れなければならない少し制限的なcoを感じることができます。そして、プログラムが非常に線形で、ループとifsが取るに足らないものである場合、私はそれを使用する必要がないと考えています。

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

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

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