何かを生成できる場合、それはコードではなくデータです。

それを考えると、ソースコード生成のこの考え全体は誤解ではないでしょうか？つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。

パフォーマンス上の理由で行われている場合、それはコンパイラの欠点のように聞こえます。

2つの言語を橋渡しするために行われている場合、それはインターフェースライブラリの欠如のように聞こえます。

ここに何かが足りませんか？

コードもデータであることを知っています。私が理解していないのは、なぜソースコードを生成するのですか？なぜそれをパラメーターを受け入れ、それらに作用することができる関数にしませんか？

ソースコード生成はアンチパターンですか？

技術的には、コードを生成する場合、人間が読めるテキストであってもソースではありません。 ソースコードは、人間またはその他の真の知性によって生成されたオリジナルコードであり、機械的に翻訳されておらず、（真の）ソースから（直接的または間接的に）すぐに再現可能ではありません。

何かを生成できる場合、それはコードではなくデータです。

とにかくすべてがデータだと思います。ソースコードも。 特にソースコード！ ソースコードは、プログラミングタスクを実行するために設計された言語の単なるデータです。このデータは、必要に応じて他の形式のデータに変換、解釈、コンパイル、生成され、その一部は実行可能になります。

プロセッサはメモリから命令を実行します。データに使用されるのと同じメモリ。プロセッサが命令を実行する前に、プログラムはデータとしてメモリにロードされます。

そのため、すべてがデータ、さらにはコードです。

[生成されたコードはデータ]であることを考えると、このコード生成の考え全体が誤解ではないでしょうか？

コンパイルに複数のステップがあり、その1つがテキストとしての中間コード生成である場合もあります。

つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。

それは一つの方法ですが、他にもあります。

コード生成の出力はテキストであり、これは人間が使用するように設計されたものです。

すべてのテキスト形式が人間が使用するためのものではありません。特に、生成されたコード（テキストとして）は通常、人間が消費するのではなく、コンパイラーが消費することを目的としています。

ソースコードはオリジナルと見なされます。マスター—編集および開発するもの。ソースコード管理を使用してアーカイブするもの。生成されたコードは、人間が読み取れるテキストであっても、通常は元のソースコードから再生成されます。生成されたコードは、一般的に言えば、ビルド中に再生成されるため、ソース管理下にある必要はありません。

実用的な推論

OK、コードもデータであることを知っています。私が理解していないのは、なぜソースコードを生成するのですか？

この編集から、理論的なコンピューターサイエンスではなく、実用的なレベルで質問していると思います。

Javaのような静的言語でソースコードを生成する古典的な理由は、そのような言語には、非常に動的なことを行うための使いやすい言語内ツールが実際に付属していなかったからです。たとえば、Javaの形成期には、動的な名前（DBのテーブル名と一致）のクラスと動的なデータ型（そのテーブルの属性と一致）のクラスを簡単に作成することはできませんでした上記の属性のタイプ）。特に Javaはコンパイル時に型エラーをキャッチできることを重要視しますが、いや、保証します。

そのため、このような設定では、プログラマはJavaコードを作成し、手動で多くのコード行を記述することしかできません。多くの場合、プログラマはテーブルが変更されるたびに、戻って一致するようにコードを変更する必要があることに気付くでしょう。そして、彼がそれを忘れると、悪いことが起こります。したがって、プログラマーは彼のためにそれを行ういくつかのツールを作成するポイントに到達します。したがって、道はますますインテリジェントなコード生成になります。

（はい、その場でバイトコードを生成できますが、Javaでそのようなことをプログラミングすることは、数行のドメインコードを書く間にランダムプログラマが行うことではありません。）

これを非常に動的な言語、たとえばRubyなど、ほとんどの点でJavaに対するアンチテーゼと見なす言語と比較してください（どちらのアプローチも評価せずにこれを言っていることに注意してください。単に違います）。ここでは、実行時にクラス、メソッドなどを動的に生成することは100％通常であり、最も重要なことは、プログラマが「メタ」レベルに進まずにコード内でそれを簡単に行えることです。はい、Ruby on Railsのようなものにはコード生成が付属していますが、基本的に新しいプログラマー向けの高度な「チュートリアルモード」として使用していることがわかりましたが、しばらくすると不要になります（コードが少ないため）そのエコシステムに書き込むには、自分が何をしているのかがわかっているときに、生成されたコードをクリーンアップするよりも手動で書くほうが速くなります）。

これらは、「実世界」からの2つの実用的な例にすぎません。次に、コードが文字通りデータであるLISPのような言語があります。一方、コンパイルされた言語（JavaやRubyなどのランタイムエンジンなし）には、実行時にクラス名やメソッド名を定義するという概念がまったくありません（または、最新のC ++機能に追いついていませんでした...）。したがって、コード生成のビルドプロセスは、ほとんどの場合に最適なツールです（その他のC / C ++固有の例は、flex、yaccなどです）。

なぜコードを生成するのですか？

パンチカード（またはメモ帳の代替コード）を使用したプログラミングは苦痛だからです。

パフォーマンス上の理由で行われている場合、それはコンパイラの欠点のように聞こえます。

本当です。強制されない限り、パフォーマンスは気にしません。

2つの言語を橋渡しするために行われている場合、それはインターフェースライブラリの欠如のように聞こえます。

うーん、何を言っているのかわかりません。

このように見えます：生成され保持されたソースコードは、常に永遠に苦痛です。理由は1つだけです。他の誰かが別の言語で作業することを主張している間、誰かが1つの言語で作業することを望んでおり、どちらも彼らの間で相互運用する方法を見つけ出すのに悩むことができないので、彼らの1人は自分の好きな言語を課された言語に変換する方法を見つけ出します彼らが欲しい。

私がそれを維持する必要があるまで、これは問題ありません。その時点で、あなたはすべて死ぬことができます。

アンチパターンですか？ため息、いや。以前の言語の欠点に別れを告げる意思がなければ、多くの言語は存在しません。古い言語のコードを生成することが、新しい言語の始まりです。

それは、私が我慢できない半分変換されたフランケンシュタインのモンスターパッチワークに残っているコードベースです。生成されたコードは、触れられないコードです。私は触れられないコードを見るのが嫌いです。それでも人々はそれをチェックインし続けます。なぜですか？実行可能ファイルをチェックインすることもできます。

さて、私は暴言を言っています。私のポイントは、すべて「コードを生成する」ことです。生成されたコードをソースコードのように扱うとき、私は夢中になります。ソースコードがソースコードにならないように見えるからです。

ソースコードを生成する理由

私のキャリアで一緒に仕事をしなければならなかったコードジェネレーターの最も頻繁なユースケースは、ジェネレーターでした。

• 何らかの種類のデータモデルまたはデータベーススキーマの高レベルのメタ記述を入力として使用しました（リレーショナルスキーマ、または何らかの種類のXMLスキーマなど）

• 出力としてのデータアクセスクラスのボイラープレートCRUDコード、および対応するSQLやドキュメントなどの追加のコードを生成しました。

ここでの利点は、短い入力仕様の1行から、5行から10行のデバッグ可能で、タイプセーフでバグのない（コードジェネレーターの出力が成熟していると仮定した）コードを手作業で実装および保守する必要があることです。これにより、メンテナンスと進化の労力がどれだけ削減されるか想像できます。

最初の質問にも答えさせてください

ソースコード生成はアンチパターンですか

いいえ、ソースコード生成自体ではありませんが、実際にはいくつかの落とし穴があります。The Pragmatic Programmerで述べたように、理解しにくいコードを生成するときはコードジェネレーターの使用を避けるべきです。そうでない場合、このコードを使用またはデバッグするための労力の増加は、コードを手動で記述しないことによって節約される労力を簡単に上回る可能性があります。

また、再生成によって手動の変更が上書きされないように、生成されたコードの部分を手動で記述されたコードから物理的に分離することをお勧めします。ただし、古い言語Xで記述されたコードを別のより現代的な言語Yに移行し、その後言語Yでメンテナンスすることを目的とする状況にも複数回対処しました。これは有効な使用方法ですワンタイムコード生成の場合。

なぜソースコードを生成するのですか？

生成された（ビルド時に、チェックインされなかった）コードの2つのユースケースに遭遇しました：

1. そのようなことを指定するために構築された言語から、getter / setter、toString、equals、hashCodeなどのボイラープレートコードを自動的に生成します（Javaのプロジェクトlombokなど）
2. メインコードで使用するインターフェイス仕様（REST、SOAPなど）からDTO型クラスを自動的に生成します。これは言語ブリッジの問題に似ていますが、生成されたクラスなしで同じものを実装しようとするよりも、型の処理が改善され、より簡潔でシンプルになります。

Sussmannは、主にコードとデータの二重性について、古典的な「コンピュータープログラムの構造と解釈」でそのようなことについて話すのが非常に面白かったです。

私にとってアドホックコード生成の主な用途は、利用可能なコンパイラを使用して、小さなドメイン固有の言語をプログラムにリンクできるものに変換することです。BNFを考え、ASN1を考えて（実際には、見た目が悪く、いです）、データ辞書のスプレッドシートを考えてください。

些細なドメイン固有の言語は時間を大幅に節約でき、標準的な言語ツールでコンパイルできるものを出力することは、そのようなものを作成するときに行く方法です。書き込み、または自動生成されたもののBNF？

テキストを出力し、それをシステムコンパイラに渡すことで、考えずにすべてのコンパイラの最適化とシステム固有の構成を取得します。

コンパイラ入力言語を別の中間表現として効果的に使用していますが、問題は何ですか？テキストファイルは本質的にソースコードではなく、コンパイラのIRである可能性があります。CまたはC ++またはJavaなどのように見える場合、誰が気にしますか。

おもちゃ言語パーサーのOUTPUTを編集する可能性があると考えるのが難しい場合、次に誰かが入力言語ファイルを編集して再構築するときに明らかに失望するでしょう、答えは自動生成されたIRをレポにコミットしないことですあなたのツールチェーンによって生成されます（そして、あなたの開発グループにそのような人々がいることは避けてください、彼らは通常、マーケティングでより幸せです）。

これは、仕様の一部を自動的にコードに変換できる形式にしたり、通常ははるかに少なくなるという事実の表現として、私たちの言語の表現力の失敗ではありませんバグやメンテナンスがはるかに簡単になります。テストと設定の担当者が調整できるスプレッドシートと、そのデータを取得して実行するツールを提供できれば、ECUのフラッシュ用に完全な16進ファイルを吐き出し、手動で翻訳するよりも大幅に時間を節約できますその日の言語での定数セットへの最新のセットアップ（タイプミスで完了）。

Simulinkでモデルを構築し、RTWでCを生成し、意味のあるツールを使用してターゲットにコンパイルする場合も同様です。中間Cは判読できません。高レベルのMatlab RTWスタッフはCのサブセットのみを知る必要があり、Cコンパイラがプラットフォームの詳細を処理します。人間が生成されたCを探し回るのは、RTWスクリプトにバグがあるときだけです。そのようなことは、名目上人間が読めるIRを使用するよりも、バイナリ解析ツリーを使用する方がはるかに簡単です。

もちろん、バイトコードや実行可能コードを出力するようなものを書くこともできますが、なぜそうするのでしょうか？IRをそれらのものに変換するツールを入手しました。

実用的な答え：コード生成は必要で便利ですか？それは本当に非常に有用で、独自のコードベースに必要なものを提供しますか、それとも、次善の結果のために知的オーバーヘッドを増やす方法で物事を行う別の方法を作成するように見えますか？

OK、コードもデータであることを知っています。私が理解していないのは、なぜコードを生成するのですか？なぜそれをパラメーターを受け入れ、それらに作用することができる関数にしてみませんか？

この質問をする必要があり、明確な答えがない場合、おそらくコード生成は不要であり、単に異国情緒とコードベースに多大な知的オーバーヘッドをもたらすだけです。

一方、OpenShadingLanguageのようなものを取る場合：https : //github.com/imageworks/OpenShadingLanguage

...そのような質問は、印象的な結果によってすぐに答えられるため、提起する必要はありません。

OSLはLLVMコンパイラフレームワークを使用して、シェーダーネットワークをオンザフライ（ジャストインタイム、または「JIT」）でマシンコードに変換し、その過程でシェーダーパラメーターおよびその他のランタイム値を完全に把握して、シェーダーとネットワークを大幅に最適化しますシェーダーがソースコードからコンパイルされたときに知られています。その結果、OSLシェーディングネットワークは、Cで手作りされた同等のシェーダーよりも25％高速に実行されます。（これが、古いシェーダーがレンダラーでどのように機能したかです。）

このような場合、コードジェネレーターの存在を疑問視する必要はありません。このタイプのVFXドメインで作業している場合、通常、「シャットダウンしてお金を取りなさい！」という行に即答します。または、「うわー、私たちもこのようなものを作る必要があります。」

いいえ、中間コードの生成はアンチパターンではありません。あなたの質問の他の部分「なぜそれをするのか？」への答えは、非常に幅広い（そして別々の）質問ですが、とにかくいくつかの理由を述べます。

中間の人間が読めるコードを持たないことの歴史的な影響

CとC ++は最も有名な言語の1つであるため、例として取り上げましょう。

Cコードをコンパイルする論理的な行列は、マシンコードではなく、人間が読み取れるアセンブリコードを出力することに注意してください。同様に、古いC ++コンパイラは、C ++コードをCコードに物理的にコンパイルするために使用されていました。この一連のイベントでは、人間が読み取れるコード1から人間が読み取れるコード2、人間が読み取れるコード3、マシンコードの順にコンパイルできます。"なぜ？" 何故なの？

中間の人間が読み取れるコードが生成されなかった場合、 CまたはC ++ さえまったくないかもしれません。それは確かに可能性です。人々は目標への抵抗が最も少ない道を歩み、C開発の停滞のために他の言語が最初に勢いをつけた場合、Cはまだ若いうちに死んだかもしれません。もちろん、「しかし、その場合は、他の言語を使用している可能性があり、おそらくそれがより良いでしょう」と主張することができます たぶん、あるいはもっと悪いだろう。それとも、私たちはまだアセンブリで書いているでしょう。

なぜ人間が読める中間コードを使用するのですか？

1. ビルドの次のステップの前に修正できるように、中間コードが必要な場合があります。この点が最も弱いことを認めます。
2. オリジナルの作業が人間が読める言語で行われたのではなく、GUIモデリングツールで行われたことが原因である場合があります。
3. 時々非常に反復的な何かをする必要があり、言語はあなたがやっていることに応えるべきではありません君は。
4. 時には非常に反復的なことをする必要があり、一般的な方法で言語に必要なものを取り込む方法はありません。言語の文法で表現できないか、それとも矛盾します。
5. コンピューターの目標の1つは、人間の労力を削減することです。また、場合によっては二度と触れられない（保守の可能性が低い）コードは、10倍の時間で長いコードを生成するためにメタコードを書くことができます。2週間ではなく1日でそれを行うことができ、それが維持される可能性が低い場合、それを生成する方が良いでしょう-そして、5年後の誰かが実際にそれを維持する必要があるためいらいらする可能性があります必要に応じて2週間かけて完全に書き出すか、厄介なコードを1週間維持することに悩まされます（ただし、その時点ではまだ1週間先です）。それは、メンテナンスを行う必要がある場合です。 。
6. 見落としている理由は他にもあると思います。

例

他のドキュメントのデータや情報に基づいてコードを生成する必要がある前に、プロジェクトに取り組んできました。たとえば、あるプロジェクトでは、スプレッドシートで定義されたネットワークメッセージと定数データのすべてと、スプレッドシートを通過してこれらのメッセージを処理できる多くのC ++およびJavaコードを生成するツールがありました。

私はそれがそのプロジェクトをセットアップする最良の方法だと言っているわけではありません（私はそのスタートアップの一部ではありませんでした）が、それは私たちが持っていたものであり、それは数百（おそらく数千、確かではない）の構造とオブジェクトと定数でした生成されていた; その時点で、ラプソディのようなものでそれをやり直そうとするのはおそらく遅すぎます。しかし、それがRhapsodyのようなものでやり直されたとしても、とにかくRhapsodyから生成されたコードがあります。

また、スプレッドシートにすべてのデータを保持することは、ある意味で優れていました。ソースコードファイルだけではデータを表現できませんでした。

例2

コンパイラー構築でいくつかの作業を行ったとき、Antlrツールを使用して、字句解析と解析を行いました。言語文法を指定し、ツールを使用してC ++またはJavaで大量のコードを吐き出し、その生成されたコードを自分のコードと一緒に使用してビルドに含めました。

他にどのようにそれを行うべきでしたか？おそらく、別の方法を考え出すことができます。おそらく他の方法があります。しかし、その作業のために、他の方法は生成されたlex / parseコードよりも良くなかったでしょう。

不足しているのは再利用です。

ソースコードテキストをバイナリに変換するコンパイラと呼ばれるすばらしいツールがあります。その入力は明確に定義されており（通常！）、最適化の方法を改良するために多くの作業を行ってきました。実際にコンパイラを使用して一部の操作を実行する場合は、独自のコンパイラを作成せずに、既存のコンパイラを使用する必要があります。

多くの人々が新しいプログラミング言語を発明し、独自のコンパイラを作成しています。ほとんど例外なく、彼らはすべて、この言語が提供する機能を必要とするのではなく、挑戦を楽しんでいるので、これを行っています。彼らが行うことはすべて、別の言語で行うことができます。彼らはそれらの機能が好きなので、単に新しい言語を作成しています。しかし、それがうまくいかないのは、適切に調整された高速で効率的な最適化コンパイラです。もちろん、テキストをバイナリに変換できるものを取得しますが、既存のすべてのコンパイラーほど優れたものではありません。

テキストは、人間が読み書きするだけのものではありません。コンピューターも完全にテキストで家にいます。実際、XMLなどの形式（およびその他の関連形式）は、プレーンテキストを使用しているため成功しています。多くの場合、バイナリファイル形式は不明瞭で文書化が不十分であり、読者はその動作を簡単に見つけることができません。XMLは比較的自己文書化されているため、XML形式のファイルを使用するコードを簡単に記述できます。また、すべてのプログラミング言語は、テキストファイルを読み書きするように設定されています。

それで、あなたの生活を楽にするために新しい施設を追加したいとします。おそらく、GUIレイアウトツールでしょう。おそらく、Qtが提供するシグナルとスロットのインターフェイスでしょう。おそらく、TIのCode Composer Studioを使用して、使用しているデバイスを構成し、適切なライブラリをビルドに取り込むことができます。おそらく、データディクショナリを取得し、typedefとグローバル変数定義を自動生成しているのでしょう（はい、これはまだ組み込みソフトウェアでは非常に重要なことです）。それが何であれ、既存のコンパイラを活用する最も効率的な方法は、何でも設定を行い、選択した言語でコードを自動的に生成するツールを作成することです。

何が起こっているかを知っていて、それが吐き出すソースコードを読むことができるので、開発とテストが簡単です。GCCに匹敵するコンパイラーを構築するのに何年も費やす必要はありません。完全に新しい言語を学ぶ必要も、他の人に要求する必要もありません。この小さな領域を自動化するだけで、他のすべては同じままです。仕事完了。

ソースコードとソースコードではなく、その理由に焦点を当てた、より実用的な答えです。ソースコードの生成は、このすべてのケースでビルドプロセスの一部であることに注意してください。そのため、生成されたファイルはソース管理への道を見つけるべきではありません。

相互運用性/シンプルさ

Googleのプロトコルバッファーを例にとると、単一の高レベルプロトコル記述を作成し、それを使用して複数の言語で実装を生成できます。多くの場合、システムの異なる部分は異なる言語で記述されます。

実装/技術的な理由

TypeScriptを使用する-ブラウザーが解釈できないため、ビルドプロセスはトランスパイラー（コードからコードへのトランスレーター）を使用してJavaScriptを生成します。実際、多くの新しいまたは難解なコンパイル言語は、適切なコンパイラを取得する前にCにトランスコンパイルすることから始まります。

使いやすさ

Cで記述され、単一のバイナリ（RTOSまたはOSなし）のみを使用する組み込みプロジェクト（IoTを考える）の場合、直接リンクするのではなく、通常のソースコードのようにコンパイルされるデータを含むC配列を生成するのは非常に簡単ですリソースとして。

編集

protobufの拡張：コード生成により、生成されたオブジェクトを任意の言語のファーストクラスにすることができます。コンパイルされた言語では、ジェネリックパーサーは必然的にキーと値の構造を返します。つまり、多くの定型コードが必要になり、コンパイル時のチェック（特にキーと値のタイプ）を逃し、パフォーマンスが低下します。コード補完なし。void*Cのすべてのものまたはstd::variantC ++の巨大なもの（C ++ 17がある場合）を想像してください。一部の言語にはこのような機能がまったくない場合があります。

ソースコード生成はアンチパターンですか？

これは、表現力が不十分なプログラミング言語の回避策です。適切な組み込みのメタプログラミングを含む言語でコードを生成する必要はありません。

ソースコードの生成は、常にアンチパターンではありません。たとえば、現在、特定の仕様によって2つの異なる言語（JavascriptとJava）でコードを生成するフレームワークを書いています。フレームワークは、生成されたJavascriptを使用してユーザーのブラウザーアクションを記録し、SeleniumのJavaコードを使用して、フレームワークがリプレイモードのときに実際にアクションを実行します。コード生成を使用しなかった場合、両方が常に同期していることを手動で確認する必要がありますが、これは面倒であり、何らかの形で論理的な重複でもあります。

ただし、ジェネリックなどの機能を置き換えるためにソースコード生成を使用している場合は、アンチパターンです。

ここに何かが足りませんか？

たぶん、中間コードが成功の理由であることが判明した良い例でしょうか？HTMLを提供できます。

HTMLがシンプルで静的であることが重要だと思います-ブラウザを簡単に作成できるようにし、モバイルブラウザを早期に起動できるようにしました。さらなる実験（Javaアプレット、Flash）が示すように- 。ユーザーは実際にはJavaアプレットによって危険にさらされており、そのようなWebサイトにアクセスすることは、DC ++経由でダウンロードしたゲームクラックを試すのと同じくらい安全であることがわかります。一方、プレーンHTMLは、デバイスのセキュリティを合理的に信じて任意のサイトをチェックアウトできるほど無害です。

ただし、HTMLは、コンピューターで生成されたものではない場合、現在の場所には近づきません。私の答えは、誰かが手動でデータベースからHTMLファイルに書き換えるまで、このページには表示されません。幸いなことに、ほとんどすべてのプログラミング言語で使用可能なHTMLを作成できます。

つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。

生成された中間コードとしてHTMLを使用するよりも、質問とすべての回答とコメントをユーザーに表示するより良い方法を想像できますか？

なぜソースコードを生成するのですか？

なぜなら、特に面倒で繰り返しの多いタスクの場合、コードを手動で書くよりも高速で簡単（エラーが発生しにくい）であるためです。また、高レベルのツールを使用して、1行のコードを記述する前に設計を検証および検証することもできます。

一般的な使用例：

• RoseやVisual Paradigmなどのモデリングツール。
• 高ERの組み込みSQLまたはコンパイル何かに前処理されなければならないインタフェース定義言語のようなレベルの言語。
• flex / bisonのようなレクサーおよびパーサージェネレーター。

「なぜそれを関数にして直接パラメーターを渡すだけではないのか」に関しては、上記のどれもそれ自体が実行環境ではないことに注意してください。それらに対してコードをリンクする方法はありません。

場合によっては、プログラミング言語に必要な機能がないだけで、必要な機能を実行する関数やマクロを書くことが実際には不可能になります。または、あなたがやりたいことができるかもしれませんが、それを書くコードはcodeいでしょう。次に、単純なPythonスクリプト（または同様のスクリプト）を使用して、ビルドプロセスの一部として必要なコードを生成#includeし、実際のソースファイルに組み込むことができます。

これをどうやって知るのですか？それは、さまざまな異なるシステム、最近ではSourcePawnで作業するときに何度も到達したソリューションだからです。ソースコードの単純な行を解析し、生成されたコードの2つまたは3つの行を生成する単純なPythonスクリプトは、そのような行が2ダースになる（すべてのcvarを作成する）ときに、生成されたコードを手動で作成するよりもはるかに優れています。

デモ/サンプルソースコードが必要な場合は入手可能です。

テキスト形式は、人間が簡単に消費するために必要です。また、コンピューターはテキスト形式のコードを非常に簡単に処理します。したがって、生成されたコードは、コンピューターで最も簡単に生成および消費できる形式で生成される必要があります。これは非常に頻繁に読み取り可能なテキストです。

そして、コードを生成するとき、コード生成プロセス自体はしばしば人間によってデバッグされる必要があります。生成されたコードが人間が読める形式であると、人間がコード生成プロセスの問題を検出できるため、非常に便利です。結局のところ、誰かがコードを生成してコードを生成する必要があります。薄い空気では起こりません。

一度だけコードを生成する

すべてのソースコードの生成が、何らかのコードを生成し、その後、それに触れることはありません。その後、更新が必要なときに元のソースから再生成します。

コードを1回だけ生成し、元のソースを破棄して、新しいソースを維持することもあります。

これは、ある言語から別の言語にコードを移植するときに発生することがあります。特に、元の新しい変更を後で移植したくない場合（たとえば、古い言語コードが維持されない、または実際に完了している場合（たとえば、数学機能の場合））。

よくあるケースの1つは、これを行うためのコードジェネレーターを記述すると、実際にコードの90％しか正しく変換されない可能性があることです。その後、最後の10％を手作業で修正する必要があります。これは、手作業で100％翻訳するよりもはるかに高速です。

このようなコードジェネレータは、多くの場合、完全な言語トランスレータ（Cythonやf2c）が生成するコードジェネレータの種類とは非常に異なります。目標はコードを1回維持することです。彼らは、彼らがしなければならないことを正確に行うために、しばしば1回限りで作られます。多くの点で、正規表現/検索置換を使用してコードを移植する次のレベルのバージョンです。「ツール支援ポーティング」と言えます。

ウェブサイトのスクレイプなどからコードを一度だけ生成します。

密接に関連するのは、再度アクセスしたくないソースからコードを生成する場合です。たとえば、コードを生成するために必要なアクションが再現性がない、一貫性がない、またはそれらの実行に費用がかかる場合。現在、DataDeps.jlと DataDepsGenerators.jlの 2つのプロジェクトに取り組んでい ます。

DataDeps.jlは、ユーザーがデータをダウンロードするのに役立ちます（標準のMLデータセットなど）。これを行うには、RegistrationBlockと呼ばれるものが必要です。これは、ファイルのダウンロード元、チェックサムなどのメタデータを指定するコードであり、ユーザーにデータの条件/条件/ライセンスステータスを説明するメッセージです。

これらのブロックを書くのは面倒です。そして、その情報は、多くの場合、データがホストされているWebサイトの（構造化または非構造化）から入手できます。そのため、DataDepsGenerators.jlは、大量のデータをホストする一部のサイトに対して、webscraperを使用してRegistrationBlockCodeを生成します。

正しく生成されない場合があります。したがって、生成されたコードを使用する開発者は、それをチェックして修正する必要があります。オッズは、たとえばライセンス情報を間違えないようにしたいということです。

重要なことに、DataDeps.jlを使用するユーザー/開発者は、生成されたRegistrationBlockコードを使用するためにwebscraperをインストールまたは使用する必要はありません。（Webスクレーパーをダウンロードしてインストールする必要がないため、かなりの時間を節約できます。特にCI実行の場合）

ソースコードを一度生成することはアンチパターンではありません。通常、メタプログラミングに置き換えることはできません。

「ソース」コードの生成は、生成される言語の欠点を示しています。これを克服するツールを使用してアンチパターンですか？絶対にありません-説明させてください。

通常、コード生成が使用されるのは、結果のコードを記述できる上位レベルの定義が存在し、下位レベルの言語よりもはるかに冗長性が低いためです。したがって、コード生成は効率と簡潔さを促進します。

c ++を書くときは、アセンブラーやマシンコードを使用するよりも効率的にコードを書くことができるため、そうします。それでも、マシンコードはコンパイラによって生成されます。当初、c ++はCコードを生成する単なるプリプロセッサでした。汎用言語は、汎用動作の生成に最適です。

同様に、DSL（ドメイン固有言語）を使用することで、簡潔に記述できますが、特定のタスクに限定されたコードを作成できます。これにより、コードの正しい動作を生成するのが簡単になります。コードは手段であり終了であることに注意してください。開発者が探しているのは、動作を生成する効率的な方法です。

理想的には、ジェネレーターは、操作と理解がより簡単な入力から高速コードを作成できます。これが満たされる場合、ジェネレーターを使用しないことはアンチパターンです。このアンチパターンは通常、「純粋な」コードが「よりきれい」であるという概念に由来します。これは、木材労働者や他の職人が電動工具の使用やCNCを使用してワークピースを「生成」するのと同じように（金色だと思います）ハンマー）。

一方、生成されたコードのソースは（いつかためその維持または十分なユーザが間違ったツールを使用してのトラップに落ちて効率的でないコードを生成するために困難である場合ゴールデンハンマー）。

ソースコードの生成とは、生成されたコードがデータであることを意味します。しかし、それはファーストクラスのデータであり、プログラムの残りの部分が操作できるデータです。

私が知っている、ソースコードに統合されているデータの最も一般的な2つのタイプは、ウィンドウに関するグラフィック情報（さまざまなコントロールの数と配置）とORMです。どちらの場合も、コード生成を介した統合により、データを操作するための特別な手順を追加する必要がないため、データの操作が容易になります。

元の（1984）Macで作業する場合、ダイアログとウィンドウの定義は、データをバイナリ形式で保持するリソースエディターを使用して作成されました。アプリケーションでこれらのリソースを使用することは、「バイナリ形式」がPascalであった場合よりも困難でした。

そのため、ソースコードの生成はアンチパターンではありません。データをアプリケーションの一部にすることができ、使いやすくなります。

コード生成は、達成する以上のコストがかかる場合のアンチパターンです。この状況は、AがBとほぼ同じ言語であるAからBに生成が行われた場合に発生しますが、AからBへのすべてのカスタムツールおよびビルドステージングよりも少ない労力でAをコーディングするだけで実行できるいくつかのマイナーな拡張があります。

トレードオフは、外​​部テキスト処理のステージングを通じてメタプログラミングを達成することの複雑さと不備のために、メタプログラミング機能（構造マクロ）を持たない言語でのコード生成に対してより禁止的です。

悪いトレードオフは、使用量にも関係している可能性があります。言語AはBとは大幅に異なる可能性がありますが、カスタムコードジェネレーターを使用するプロジェクト全体では、1か2つの小さな場所でのみAを使用するため、複雑さの合計（Aの小さなビットとA-> Bコードジェネレーター、さらに、周囲のビルドステージング）は、Bで行われたばかりのソリューションの複雑さを超えています。

基本的に、コード生成をコミットする場合は、おそらく「大きくなるか、家に帰る」必要があります。実質的なセマンティクスを持たせ、多く使用するか、気にしないでください。

私はこれがはっきりと述べられていなかった（私はそれが1つか2つの答えによって触れられたのを見たが、それはあまり明確に見えなかった）

コードを生成すること（あなたが言ったように、データであるかのように）は問題ではありません。これは、二次的な目的でコンパイラを再利用する方法です。

生成されたコードを編集することは、あなたが遭遇する最も陰湿で邪悪で恐ろしいアンチパターンの1つです。こんなことしないで。

せいぜい、生成されたコードを編集するだけで、多くの貧弱なコードがプロジェクトに引き込まれます（コードの完全なセットは、もはやソースコードであり、もはやデータではありません）。最悪の場合、プログラムに取り込まれたコードは冗長性が高く、名前が不適切なガベージであり、ほぼ完全に維持できません。

3番目のカテゴリは、1回使用するコード（guiジェネレーター？）であり、編集して開始/学習に役立つと思います。これは少しずつですが、開始するのに適した方法ですが、GUIジェネレーターは、プログラマーにとっては素晴らしい開始とはならない「生成可能な」コードを使用することを目標としています。さらに、冗長なソースコードをシステムに取り込むことを意味する2番目のGUIで再び使用したいと考えました。

ツールが生成されたコードの編集を一切許可しないほど賢い場合は、それを選択してください。そうでない場合、私はそれを世の中の最悪のアンチパターンの1つと呼びます。

コードとデータは両方とも情報です。

データは、必要な形式（および値）の情報です。コードも情報ですが、間接形式または中間形式です。本質的に、コードはデータの形式でもあります。

より具体的には、コードとは、人間が自分で情報を処理することから人間を解放するマシンの情報です。

人間を情報処理から解放することが最も重要な動機です。生活を楽にする限り、中間ステップは受け入れられます。それが中間情報マッピングツールが存在する理由です。コードジェネレーター、コンパイラー、トランスパイラーなど。

なぜソースコードを生成するのですか？なぜそれをパラメーターを受け入れ、それらに作用することができる関数にしてみませんか？

誰かがあなたにそのようなマッピング関数を提供し、その実装があなたにはわかりにくいとしましょう。関数が約束どおりに機能する限り、内部でソースコードを生成しているかどうか気にしますか？

何かを生成できる場合、それはコードではなくデータです。

後でそのコードがデータであると規定しているので、命題は「何かを生成できるなら、そのことはコードではない」に帰着します。では、Cコンパイラによって生成されたアセンブリコードはコードではないと言いますか？手作業で書いたアセンブリコードと正確に一致した場合はどうなりますか？お望みならそこへ行くことはできますが、私はあなたと一緒にはいません。

代わりに、「コード」の定義から始めましょう。技術的になりすぎることなく、この説明の目的のためのかなり良い定義は、「計算を実行するための機械で実行可能な命令」です。

それを考えると、ソースコード生成のこの考え全体は誤解ではないでしょうか？

はい、あなたの最初の命題はコードを生成できないことですが、私はその命題を拒否します。「コード」の私の定義を受け入れれば、一般的なコード生成に概念的な問題はないはずです。

つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。

まあ、それはその性質ではなく、コード生成を採用する理由についてのまったく異なる質問です。コードジェネレータを作成または使用する代わりに、結果を直接計算する関数を作成するという代替案を提案しています。しかし、どの言語で？誰もがマシンコードで直接書く時代は過ぎ去り、他の言語でコードを書く場合、実際に実行するプログラムを生成するためにコンパイラーやアセンブラーの形のコードジェネレーターに依存します。

では、なぜJava、C、Lisp、その他何でも書くのが好きですか？アセンブラーですか？これらの言語は、実行したい計算の詳細を簡単に表現できるデータと操作の抽象化を提供するため、少なくとも部分的にはそうだと断言します。

同じことは、ほとんどの高レベルのコードジェネレーターにも当てはまります。プロトタイプの場合は、おそらくのようなスキャナとパーサジェネレータですlexとyacc。はい、スキャナーまたはパーサーをCまたは選択した他のプログラミング言語（未加工のマシンコードでさえ）で直接書くことができます。ただし、非常に複雑な問題の場合、lexやyaccなどの高レベルの専用言語を使用すると、手書きコードの記述、読み取り、および保守が容易になります。通常、はるかに小さくなります。

また、「コードジェネレータ」が何を意味するのかを正確に考慮する必要があります。Cの前処理とC ++テンプレートのインスタンス化は、コード生成の演習であると考えています。これらに反対しますか？そうでない場合は、メンタル体操をいくつか実行して、それらを受け入れるがコード生成の他のフレーバーを拒否することを合理化する必要があると思います。

パフォーマンス上の理由で行われている場合、それはコンパイラの欠点のように聞こえます。

どうして？基本的には、ユーザーがデータをフィードするユニバーサルプログラムが必要であり、一部は「命令」に、その他は「入力」に分類され、計算を実行して「出力」と呼ばれるデータをさらに出力します。（特定の観点から、そのような汎用プログラムを「オペレーティングシステム」と呼ぶかもしれません。）プログラム？2つのプログラムには、異なる特性と異なる機能があります。

2つの言語を橋渡しするために行われている場合、それはインターフェースライブラリの欠如のように聞こえます。

普遍的なものからある程度のインターフェースライブラリを持っていることは、必然的に良いことだと言います。おそらくそうなりますが、多くの場合、そのようなライブラリは大きくて記述や保守が難しく、さらには遅くなることさえあります。そして、実際にそのような獣が手元の特定の問題に対処するために存在しない場合、コード生成アプローチが問題をはるかに迅速かつ簡単に解決できる場合、誰が作成することを主張しますか？

ここに何かが足りませんか？

いくつかのことを考えます。

コードもデータであることを知っています。私が理解していないのは、なぜソースコードを生成するのですか？なぜそれをパラメーターを受け入れ、それらに作用することができる関数にしてみませんか？

コードジェネレーターは、ある言語で記述されたコードを、通常は低レベルの別の言語のコードに変換します。それでは、なぜ人々が複数の言語を使用してプログラムを作成したいのか、特に主観的に異なるレベルの言語を混在させたいのではないかと尋ねています。

しかし、私はすでにそれに触れました。特定のタスクの明快さと表現力に一部基づいて、特定のタスクの言語を選択します。コードが小さいほど平均してバグが少なく、保守が容易であるため、少なくとも大規模な作業では、高レベルの言語へのバイアスもあります。しかし、複雑なプログラムには多くのタスクが関係しており、多くの場合、ある言語でより効果的に対処できるものもあれば、別の言語でより効果的または簡潔に対処できるものもあります。ジョブに適切なツールを使用することは、コード生成を使用することを意味する場合があります。

コメントのコンテキスト内で質問に答える：

コンパイラの義務は、人間が読み取れる形式で記述されたコードを取得し、それを機械が読み取れる形式に変換することです。したがって、コンパイラが効率的なコードを作成できない場合、コンパイラは適切に機能していません。それは間違っていますか？

コンパイラがタスクに最適化されることはありません。その理由は簡単です。多くのタスクを実行するように最適化されています。これは、多くの異なるタスクのために多くの人が使用する汎用ツールです。タスクが何であるかがわかれば、ドメイン固有の方法でコードにアプローチし、コンパイラーができないトレードオフを行うことができます。

例として、私はアナリストがいくつかのコードを書く必要があるソフトウェアに取り組んできました。アルゴリズムをC ++で記述し、依存するすべての境界チェックとメモ化のトリックを追加できますが、そのためにはコードの内部動作について多くを知る必要があります。彼らはむしろ単純なものを書いて、最終的なC ++コードを生成するためのアルゴリズムを投げさせます。その後、分析者が耐えることを期待しない静的分析のようなパフォーマンスを最大化するために、エキゾチックなトリックを行うことができます。コード生成により、ドメイン固有の方法で記述できるため、汎用ツールよりも簡単に製品を入手できます。

私も正反対を行いました。「コードを生成しない」という任務を持った、もう1つの仕事があります。それでも、ソフトウェアを使用している人の生活を楽にしたかったので、大量のテンプレートメタプログラミングを使用して、コンパイラがその場でコードを生成できるようにしました。したがって、私は自分の仕事をするために汎用C ++言語のみが必要でした。

ただし、キャッチがあります。エラーが読み取り可能であることを保証することは非常に困難でした。以前にテンプレートメタプログラミングコードを使用したことがある場合、1回の無害なミスが、何が間違っているかを理解するために100行の理解できないクラス名とテンプレート引数を必要とするエラーを生成することがあります。この効果は非常に顕著であったため、構文エラーの推奨されるデバッグプロセスは、「自分のファイルの1つにエラーが発生するまで、エラーログをスクロールします。間違っていました。」

コード生成を使用していた場合、人間が読み取れるエラーを含む、はるかに強力なエラー処理機能を使用できたはずです。C'est la vie。

コード生成を使用する方法はいくつかあります。これらは3つの主要なグループに分けることができます。

• コンパイルプロセスのステップからの出力として、異なる言語でコードを生成します。典型的なコンパイラの場合、これは低レベル言語になりますが、JavaScriptにコンパイルされる言語の場合のように、別の高レベル言語になります。
• コンパイルプロセスのステップとして、ソースコード言語でコードを生成または変換します。これがマクロの機能です。
• 通常のコンパイルプロセスとは別にツールを使用してコードを生成します。これからの出力は、通常のソースコードと共にファイルとして存在し、それと共にコンパイルされるコードです。たとえば、ORMのエンティティクラスはデータベーススキーマから自動生成されたり、データ転送オブジェクトとサービスインターフェイスはSOAPのWSDLファイルなどのインターフェイス仕様から生成されたりします。

これは最も議論の余地のある形式であるため、3番目に生成されるコードについて話しているのではないでしょうか。最初の2つの形式では、生成されたコードはソースコードから非常に明確に分離された中間ステップです。しかし、3番目の形式では、ソースコードと生成コードの間に正式な分離はありません。ただし、生成コードにはおそらく「このコードを編集しないでください」というコメントがあります。それでも、開発者が生成されたコードを編集するというリスクは開かれますが、これは本当にいものになります。コンパイラの観点から見ると、生成されるコードはソースコードです。

それにもかかわらず、生成されたコードのこのような形式は、静的に型付けされた言語で本当に役立ちます。たとえば、ORMエンティティと統合する場合、データベーステーブルに厳密に型指定されたラッパーがあると非常に便利です。実行時に統合を動的に処理することはできますが、タイプセーフとツールサポート（コード補完）は失われます。静的型言語の主な利点は、実行時だけでなく、書き込みのタイプでの型システムのサポートです。（逆に、このタイプのコード生成は、動的に型付けされた言語ではあまり普及していません。そのような言語では、実行時の変換と比較して利点がないためです。）

つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。

タイプセーフとコード補完はコンパイル時に（およびIDEでコードを記述しているときに）必要な機能ですが、通常の関数は実行時にのみ実行されるためです。

妥協点があるかもしれません：F＃は、タイププロバイダーの概念をサポートします。これは基本的に、コンパイル時にプログラムによって生成される厳密に型指定されたインターフェイスです。この概念は、おそらくコード生成の多くの用途に取って代わり、懸念事項をより明確に分離することができます。

プロセッサの命令セットは基本的に必須ですが、プログラミング言語は宣言型にすることができます。宣言型言語で書かれたプログラムを実行するには、必然的に何らかのコード生成が必要です。この回答および他の回答で述べたように、人間が読める言語でソースコードを生成する主な理由は、コンパイラによって実行される高度な最適化を利用することです。

何かを生成できる場合、それはコードではなくデータです。

間違った方法で取得しました。読むべき

何かがインタープリタブルのジェネレーターに供給できる場合、それはデータではなくコードです。

これはそのコンパイル段階のソース形式であり、シンク形式はまだコードです。