4

そこで、私はscribble/lpモジュールを使用して、plt-scheme を使用した最初の文芸プログラムを作成しました。

#lang scribble/lp
(require scribble/lp)

<<lp_scheme.ss>>

@chunk[<squarefunction>
        (define (f x)
         (* x x))]

もちろん、そこには何も役に立ちません。今、文芸的なプログラミング構造の代わりに、単純なコメントを使用しないのはなぜだろうかと思っています。任意の意見を歓迎します。おそらくより多くの露出/経験を持っている人がいれば、それは本当に素晴らしいことです. これにより、十分に文書化されたコードと Literate プログラミング構造を使用して記述されたコードとの違いをより直感的に説明できる可能性があります。

4

3 に答える 3

9

(ドナルド・クヌースの文芸的プログラミングの定義を使用していると思います。)

主な違いは、シーケンスの 1 つです。

通常の申請書の場合、記載する順番に制限があります。

説明する：

  • 特定のクラスのすべてのコードは、1 つの場所
    (または、C# 部分クラスなどの非常に少数の場所)で表現する必要があります。
  • 1 つのメソッドのすべてのコードは、正しい実行順序で一度に指定する必要があります。
  • 依存関係は、それらに依存するものより前に宣言する必要があります
    (ほとんどの言語で変数は使用前に宣言され、Pascal では使用前に宣言されたプロシージャ/関数、.NET では他のものより前にコンパイルされたライブラリ アセンブリ)

読み書きのできるプログラミングを使用すると、この制限から解放され、別の開発者にプログラムを説明するときに使用する意味のある順序で概念を表現することができます。

これには別の結果があります。いくつかの形式では、概念を 1 回表現し (「すべてのプロパティが変更されると PropertyChanged イベントが発生する」など)、それをアプリケーション全体の無数の他の場所に織り込むことができます。

非常に単純なプログラムの場合、読み書きのできるプログラムと十分にコメントされたプログラムは同じように見えるかもしれませんが、システムが複雑になるにつれて、この 2 つは非常に異なって見えるようになります。

于 2009-08-08T05:52:49.287 に答える
0

Literate Programming は、次の 3 つの簡単なステートメントに基づいています。

  1. プログラマーはコンピューターが理解できるコードを書かなければならない
  2. プログラマーは、人々が理解できるドキュメントを作成する必要があります
  3. これらが別々のドキュメントである場合、それらが非同期になることは避けられません

実際、私の経験では、#2 はたいてい短気です。QA が私に「ドキュメントはこう言っているが、コードはそれを実行している。コードが間違っているのか、それともドキュメントが古くなっているのか?」と何回言ったか数えきれないほどです。その点で、私の職場が異常だとは思いません。さらに、私の初期のプロジェクトの 1 つで、利害関係者とのやり取りによって要件が変化したため、ドキュメントを最新の状態に保つように努めていました。これには十分な時間がかかるため、経営陣から、ドキュメントをいじるのをやめてプロジェクトを機能させるように言われました。それ以来、私たちはそれほど退屈ではない文書化プロセスに移行しました (ありがたいことに!)。

コードに変更を加えると、複数の人が変更を明確に説明し、コメントを作成して質問したり、説明したり、改善を提案したりできるコード レビュー ツールがあります。コードがリテレート プログラミング テクニックを使用して記述されている場合、説明が含まれるため、この質問/回答の多くは不必要になります。

現代のプログラミングの考え方の多くは、コードは独自のドキュメントであるべきだというものです。多くの専門家は、コメントでコードを説明する必要がある場合は、コメントが不要になるようにコードを再フォーマット (変数/関数名の変更など) する必要があると主張しています。これは理論的には優れていますが、実際にはあまり実用的ではありません。つまり、他の人が作成/管理しているライブラリを使用している場合、メソッド/関数名の選択は常に直感的であるとは限りません。例えば：

Set<String> statesWeCareABout = new HashSet<String>(Arrays.asList(new String[] { "one", "two", "three" }));
Set<String> statesWeFound = <some function>;
statesWeFound.retainAll(statesWeCareAbout);

Set<> や HashSet<> に慣れていない場合は、.retainAll() が 2 つの共通部分を返し、その結果が変更された Set<> になることを知らないかもしれません。

最後に、リテレート プログラミングでは、通常、このコード部分を分離して説明し、それを他のコード部分にインライン化できるように、物事を分解できます。これは、人間の理解の仕組みとより一致しています。これがどのように機能するかを説明してから、その理解に基づいて全体像を説明してください。コンピュータはあまり気にしません。1,000 行のコードで 1 つの関数を記述でき、全体を理解するのに問題はありません。あなたが開発者としてそれを維持しなければならない場合、神はあなたを助けてくれます。

これこそが、Literate Programming の背後にある理由です。バグの修正や機能の追加など、コードを維持する必要があります。そして、他の誰かがそれを理解できない場合、後で効率的な方法で置き換えられます。この世界には、「書き込みのみ」のコードがたくさんあります。リテレート プログラミングは読みやすく、理解しやすく、長期的に保持して使用する可能性が高くなります。

そして、車輪の再発明を続ける時間は本当にあるのでしょうか?

于 2015-01-16T15:48:34.113 に答える
0

私にとっての主な動機は、すべてのプログラマーが紙のシート/ノートブックを使用してアーキテクチャを「設計」し、アイデアを開発し、そこでスキームや図を書き、数学を試したりすることです。プログラムの終了後、これらのノート/用紙はすべて失われるため、プログラムのサポート性が低下しています。これについては、私の LP ツール NanoLP の WiKi に書きました: http://code.google.com/p/nano-lp/wiki/AboutLP。

2 つ目の動機は、明確ではありませんが、バグが少ないことです。しかし、これは「理論的な」ものではなく、(私にとって) 経験上の事実です。紙の上で「考え」、図を描き、アルゴリズムのスキームを考えている場合、プログラムのバグは少なくなります。LPはそのような「紙」であり、他には何もありません。

何も描かず、コメントすらせず（！）、プログラムだけを書いている開発者がたくさんいます...ひどい！

そして、LP は適切なドキュメントを作成するのに役立ちます (正式な方法ではありません - 関数の説明、それは引数であり、それが返すものであり、これは関数シグネチャでよく知られているので、なぜそのようなドキュメントが必要なのですか??)。実際のアクションの説明を使用して、セマンティックで、写真で、REAL ACTUALドキュメントを作成します...

多くの動機:) 確かに、リバース LP (たとえば、Doxygen) のみを使用する方が良い場合もあれば、実際の LP は多くの要因に依存する場合もあります。

于 2013-01-24T06:40:57.053 に答える