5

ここでは、擬似コードが役立つかどうかについて議論を招きたくありません。それに関連する質問はたくさんあります。擬似コードを書くことは時々役に立ちますが、常に発生することの1つは、それをどのように表現するのが最善かということです。

番号付きのアプローチで終わることもあれば、Cスタイルの構文を使用することもありますが、ほとんどの場合、その時点で最適だと思うものを組み合わせたものです。それは結構ですが、6か月後にもう一度見直すと、意図が明確であるとは限りません。私が最近ページを2つに分割し始めたことに対抗するために、右半分にpidgin [ここに言語を挿入]を書き、左下に本当に明白で冗長な英語で書きます。

擬似コードを書くための「標準」はないと思いますが、他の人がどのようにそれを行うのか興味があり、それが統一されたアプローチを決定するのに役立つかもしれません。

前もって感謝します。

ああ、私はこの質問が主観的であることを知っています、そしてそれがSOの意図された目的でないなら申し訳ありませんが、それでも有効な質問です。実際、コンピューティングには、正解が1つしかない質問が本当にたくさんありますか?最も役立つ答えを正解としてマークします。

4

6 に答える 6

7

私は、インデントを使用してメモ帳で小さなユースケースを書いていることに気付く傾向があります...そして、半ダースほどの行の後、本質的にPythonのスタイルで書いていることに突然気付きますが、構文は少し少ないです! したがって、Python は実際には疑似コードであり、実際に書き込もうとしている言語が何であれ、自分の考えをプロトタイプ化するための素晴らしい方法であるという結論に達しました。この手法の最も良い点は、比較できる参照が既にあることです。厄介なバグの場合は、完成した結果。

UML シーケンス図は、何がいつ起こる必要があるかを計画するための頭の体操として書くよりも速い場合がありますが、これら 2 つの手法は、私が何度も何度も思い出すものです。

于 2009-05-12T13:58:51.310 に答える
4

私は、Steve McConnell の著書 Code Complete での疑似コードの作成に関する章が好きです。この回答は、所有していない場合は満足のいくものではないかもしれませんが、所有していない場合でも、本自体はとにかく必携です。

于 2009-05-12T13:25:37.850 に答える
2

私は疑似コードを使用したことがなく、その必要性を感じたこともありません。使用している言語に関係なく、リファクタリングに時間を割けば、コードは十分にきれいになると思います。

自分は怠け者だとか、何らかの理由で反対していると思っていたのに、他の人も同じように考えていることに気付きました

于 2009-05-12T14:04:37.430 に答える
1

英語で書くか、プログラミング言語の表現を混ぜて書くことから始めます。次に、段階的に英語をプログラミング言語の式に置き換え、時には英語の単語をコメントとして残します。それから - 出来上がり - テスト関数があるので、疑似コード + TDD を 1 つのアプローチにまとめたようなものです。ただし、難しいタスクを解決したり、簡単ではない新しいクラスを設計したりする必要がある場合にのみ、このアプローチを常に使用するわけではないことに注意する必要があります。

于 2009-05-12T13:25:36.697 に答える
1

私は一般的に、あらゆる種類のコード言語を完全に避け、プログラムの特定の時点で何が起こりたいかについてコメントを書きます。コメントがすべて終わったら、あとは空白を埋めるだけです。

于 2009-05-12T13:33:05.777 に答える
1

疑似コードも便利だと思います。あなたの 2 ページのアプローチは良さそうですね。Literate Programmingも調べてください。私は通常、LP ツールを使用しませんが、自分の考えをプログラミングする際に LP スタイルを使用することがよくあります。

于 2009-05-12T13:41:35.213 に答える