質問

実用的なプログラマー コードジェネレーターの使用を推奨しています。プロジェクトでコード ジェネレーターを作成しますか?「はい」の場合、何に使用しますか?

役に立ちましたか?

解決

コード ジェネレーターが正しい議論なしで広く使用されると、コードが理解しにくくなり、保守性が低下します (ちなみに、動的 SQL も同様です)。個人的には、私はこれをいくつかの ORM ツールで使用しています。なぜなら、ここでの使用法はほとんど明白であり、場合によっては、検索パーサー アルゴリズムや最近「手動で」保守するように設計されていない文法アナライザーなどにも使用されるからです。乾杯。

他のヒント

「Pragmatic Programmer」の中で、Hunt と Thomas はパッシブ コード ジェネレーターとアクティブ コード ジェネレーターを区別しています。

パッシブ ジェネレーターは 1 回だけ実行され、その後結果を編集します。

アクティブなジェネレーターは必要なだけ実行されます。結果は置き換えられるため、決して編集しないでください。

IMO では、後者は DRY (繰り返さない) 原則に基づいているため、はるかに価値があります。

プログラムへの入力情報を 2 つの部分に分割できる場合、めったに変更されない部分 (A) (メタデータや DSL など)、およびプログラムが実行されるたびに異なる部分 (B) (ライブ入力)を使用すると、A のみを入力として受け取るジェネレーター プログラムを作成したり、B のみを入力として受け取るアドホック プログラムを作成したりできます。(これの別名は部分評価です。)

ジェネレーター プログラムは、A と B ではなく、入力 A を通過するだけでよいため、より単純です。また、頻繁に実行されないため高速である必要はなく、メモリ リークを気にする必要もありません。

アドホック プログラムは、ほとんど常に同じ入力を処理する必要がないため、高速になります (A)。A と B ではなく、入力 B についてのみ決定すればよいため、より簡単です。

生成されたアドホック プログラムを非常に読みやすくして、エラーを見つけやすくすることをお勧めします。ジェネレーターからエラーが削除されると、それらは永久に消えます。

私が取り組んだあるプロジェクトでは、チームは、厚さ 2 インチの設計仕様と長い実装スケジュールを伴う、パフォーマンスに関する懸念を伴う複雑なデータベース アプリケーションを設計しました。コード ジェネレーターを作成することで、2 人が 3 か月でその作業を完了しました。ソース コード リスト (C 言語) の厚さは約 0.5 インチで、生成されたコードは問題にならないほど高速でした。アドホック プログラムは、わずかなコストで毎週再生成されました。

それで アクティブなコード生成、 いつ使えるようになりますか, 、win-winです. 。そして、これがまさにコンパイラの動作であることは偶然ではないと思います。

ハードウェア設計では、これを「スタック」の複数のレベルで行うのが非常に一般的です。たとえば、私は、DMA エンジンとクロスバー スイッチのさまざまな幅、トポロジ、構造に対して Verilog を出力するコード ジェネレーターを作成しました。これは、このパラメーター化を表現するために必要な構造が、合成およびシミュレーション ツールのフローにおいてまだ成熟していなかったためです。

また、SRAM、キャッシュ、レジスタ ファイル構造など、アルゴリズムで表現および生成できる非常に規則的なもののレイアウト データに至るまで論理モデルを出力することも日常的です。

また、基本的に、システム オン チップ上のすべてのレジスタの XML 記述を取得し、HTML を出力するコード ジェネレーターの作成にもかなりの時間を費やしました (はい、はい、XSLT については知っています。出力することを発見しました)時間効率を高めるためにプログラム的に実行されます)、Verilog、SystemVerilog、C、アセンブリなど。さまざまなチーム (フロントエンドとバックエンドの ASIC 設計、ファームウェア、ドキュメントなど) が使用するそのデータの「ビュー」 (そして、この単一の XML 「コードベース」によってそれらの一貫性が保たれます)。それはカウントされますか?

人々はまた、例えば、有限状態マシンなどの非常に一般的なものの簡潔な説明を取得し、それらを効率的に実装するためにより冗長な命令型言語コードを機械的に出力します (例:遷移テーブルとトラバーサル コード)。

データ エンティティ クラス、データベース オブジェクト (トリガー、ストアド プロシージャなど)、サービス プロキシなどを生成するためにコード ジェネレーターを使用します。パターンに従って反復的なコードが多く、手作業が多く含まれている場合は、コード ジェネレーターが役に立ちます。ただし、メンテナンスが面倒になるまで過度に使用しないでください。再生成する場合にも、いくつかの問題が発生します。

Visual Studio や Codesmith などのツールには、ほとんどの一般的なタスク用の独自のテンプレートがあり、このプロセスを容易にします。ただし、自分で展開するのは簡単です。

仕様 (通常は規則的な表形式のルールを持つもの) からコードを生成するコード ジェネレーターを作成すると便利なことがよくあります。これにより、タイプミスや省略によってエラーが発生する可能性が低くなります。

はい、AAAプロトコルの直径(RFC 3588)の独自のコードジェネレーターを開発しました。これは、Diameter アプリケーションの文法を記述した XML ファイルから読み取った Diameter メッセージの構造と API を生成できます。

これにより、完全な直径インターフェイス (SH/CX/RO など) を開発する時間が大幅に短縮されました。

私の意見では、優れたプログラミング言語にはコードジェネレーターは必要ありません。なぜなら、イントロスペクションとランタイムコード生成は言語の一部だからです。Pythonメタクラスや新しいモジュールなどで。

コード ジェネレーターは通常、長期間使用すると管理不能なコードを生成します。

ただし、コード ジェネレーター (私はスイング開発に Eclipse VE を時々使用します) を使用することが絶対に必要な場合は、どのようなコードが生成されているかを確認してください。信じてください、馴染みのないコードをアプリケーションに含める必要はありません。

プロジェクト用に独自のジェネレーターを作成するのは効率的ではありません。代わりに、T4、CodeSmith、Zontroy などのジェネレーターを使用してください。

T4 はより複雑で、.Net プログラミング言語の知識が必要です。テンプレートを 1 行ずつ記述する必要があり、データ リレーショナル操作を自分で完了する必要があります。Visual Studio 上で使用できます。

CodeSmith は機能的なツールであり、すぐに使用できるテンプレートが豊富にあります。T4 をベースにしており、T4 のままでは独自のテンプレートを作成すると時間がかかりすぎます。体験版と製品版があります。

Zontroy は、使いやすいユーザー インターフェイスを備えた新しいツールです。独自のテンプレート言語があり、習得が簡単です。オンライン テンプレート マーケットが存在し、発展しています。テンプレートを提供し、それをオンラインで市場以外で販売することもできます。無料版と商用版があります。中規模のプロジェクトを完了するには無料版でも十分です。

世の中にはコード ジェネレーターがたくさんあるかもしれませんが、コードをより理解しやすく、使用しているフレームワークやガイドラインに適合させるために、私は常に独自のコード ジェネレーターを作成しています。

すべての新しいコードにジェネレーターを使用して、コーディング標準に確実に準拠できるようにします。

私たちは最近、社内の C++ ジェネレーターを次のように置き換えました。 コードスミス. 。ツールのテンプレートを作成する必要がありますが、自分でツールを保守する必要がないのが理想的です。

私が最近ジェネレーターを必要としていたのは、ハードウェアからデータを読み取り、最終的にそれを「ダッシュボード」UI にポストするプロジェクトでした。それらの間には、モデル、プロパティ、プレゼンター、イベント、インターフェイス、フラグなどが含まれていました。いくつかのデータポイントについて。このデザインで満足できるまで、いくつかのデータ ポイントのフレームワークを作成しました。次に、慎重に配置されたいくつかのコメントの助けを借りて、Visual Studio マクロに「世代」を配置し、マクロを微調整してクリーンアップし、世代を呼び出すためのデータポイントをマクロ内の関数に追加しました。これにより、数時間 (数日) の退屈な時間を節約できました。 ?) 最後に。

マクロの力を過小評価しないでください :)


私も今、頭を整理しようとしています コードラッシュ カスタマイズ機能を使用すると、ローカル生成の要件をさらに満たすことができます。コード ブロックの生成時にその場での意思決定が必要な場合には、強力な機能がそこにあります。

SQL テーブルに対して実行する独自のコード ジェネレーターがあります。データ、データ アクセス層、ビジネス ロジックにアクセスするための SQL プロシージャを生成します。私のコードと命名規則の標準化において、素晴らしい成果を上げてくれました。データベース テーブル内の特定のフィールド (ID 列や更新日時列など) を想定しているため、データ設計の標準化にも役立ちました。

何人探していますか?私は 2 つの大きなものと多数の小さなものを作成しました。最初の主要なプログラムでは、ファミリーに非常によく似ているものの、データベース内のさまざまなテーブルに調整された 1500 行のプログラム (ギブ・オア・テイク) を生成することができ、それを高速かつ確実に実行できました。

コード ジェネレーターの欠点は、生成されたコードにバグがある場合 (テンプレートにバグが含まれているため)、多くの修正作業が必要になることです。

ただし、ほぼ反復的なコーディングが多く行われる言語やシステムにとって、優れた (十分な) コード ジェネレーターは恩恵です (そして、「犬」よりも恩恵の方が大きいです)。

はい、いくつかメンテナンスする必要がありました。CORBA またはその他のオブジェクト通信スタイルのインターフェイスが、おそらく私が最初に思いつく一般的なものです。これから話すインターフェイスによって提供されるオブジェクト定義はありますが、それらのオブジェクトをコードで構築する必要があります。コード ジェネレーターを構築して実行するのは、非常に日常的な方法です。これは、レガシー通信チャネルをサポートするためだけにかなり長いコンパイルになる可能性があり、CORBA を単純化するためにラッパーを配置する傾向が強いため、状況はさらに悪化します。

一般に、大量の構造がある場合、または使用する必要がある構造が急速に変化する場合に、メタデータを介してオブジェクトを構築する際のパフォーマンスの低下に対処できない場合は、コード ジェネレーターを作成する必要があります。

独自のコード ジェネレーターを最初から作成する必要があったプロジェクトは思いつきませんが、既存のジェネレーターを使用したプロジェクトはいくつかあります。(エンタープライズ ソフトウェア用に Java でパーサーとモデルを構築するために、Antlr と Eclipse Modeling Framework の両方を使用しました。) 他の人が作成したコード ジェネレーターを使用する利点は、作成者がその分野の専門家である傾向があり、問題を解決していることです。まだ存在すら知らなかったこと。これにより、時間とフラストレーションが軽減されます。

そのため、目前の問題を解決するコードを書けるかもしれませんが、そのコードを生成するのがはるかに速くなり、私が書くコードよりもバグが少なくなる可能性が高くなります。

コードを書くつもりがない場合、他の人が生成したコードを使用しても問題ありませんか?

独自のコードまたはコード ジェネレーターを作成する方が、時間的にも長期的に見ても安くなりますか?

私は、DTD またはスキーマに準拠した方法でデータベースから XML データを出力する数百のクラス (Java) を構築するコード ジェネレーターを作成しました。コード生成は通常 1 回限りであり、その後コードはさまざまなビジネス ルールなどでスマート化されます。出力はかなり衒学的な銀行のものでした。

コード ジェネレーターは、プログラミング言語の制限を回避するものです。私は個人的にはコード ジェネレーターよりもリフレクションを好みますが、コード ジェネレーターの方が柔軟性が高く、実行時の結果のコードが明らかに高速であることに同意します。C# の将来のバージョンには、何らかの DSL 環境が含まれることを願っています。

私が使用するコード ジェネレーターは Web サービス パーサーだけです。私は個人的に、新入社員や引き継ぎ後の別チームのメンテナンスの問題を考慮して、コードジェネレーターには近づきません。

私は主に T-SQL で独自のコード ジェネレーターを作成し、ビルド プロセス中に呼び出されます。

メタモデル データに基づいて、トリガー、ロギング、C# const 宣言、INSERT/UPDATE ステートメント、データ モデル情報を生成し、アプリが予期されたデータベース スキーマで実行されているかどうかを確認します。

生産性を向上させ、仕様を増やし、コーディングを減らすためにフォーム ジェネレーターを作成する必要があります ;)

いくつかのコードジェネレーターを作成しました。テンプレートを使用する SQL ストアド プロシージャ用のパッシブ コード ジェネレーターがありました。これにより、ストアド プロシージャの 90% が生成されました。

Entity Framework に切り替えて以来、T4 を使用してアクティブなコードジェネレーターを作成しました (テキスト テンプレート変換ツールキット)ビジュアルスタジオ内。これを使用して、エンティティの基本的なリポジトリ部分クラスを作成しました。非常にうまく機能し、大量のコーディングを節約できます。また、エンティティ クラスを特定の属性で装飾するために T4 も使用します。

が提供するコード生成機能を使用しています EMF - Eclipse モデリング フレームワーク.

コード ジェネレーターは、多くの場合、特にある形式から別の形式にマッピングする場合に非常に役立ちます。ほんの数例を挙げると、IDL から C++ へのコード ジェネレーター、データベース テーブルから OO 型へのコード ジェネレーター、コードのマーシャリングなどを行ってきました。

著者たちが言いたいのは、もしあなたが開発者なら、コンピュータを自分のために動かせるようにすることができるべきだということだと思います。コードの生成は、自動化すべき明白なタスクの 1 つにすぎません。

私はかつて、IDL から C++ へのマッピングを手動で行うと主張した男性と仕事をしました。プロジェクトの初期は、他のメンバーが何をすべきか考えようとしていたため、彼はなんとかついていけましたが、最終的には彼がボトルネックになってしまいました。Perl でコード ジェネレーターを作成したところ、数分で彼の「仕事」をほぼ完了することができました。

私たちのを参照してください 「ユニバーサル」コードジェネレーター プログラム変換に基づいています。

私はアーキテクトであり、主要な実装者です。このジェネレーターのかなりの部分がこのジェネレーターを使用して生成されることは注目に値します。

組み込みシステムでは、フラッシュ内にバイナリ データの大きなブロックが必要になる場合があります。たとえば、ビットマップ フォント グリフを含むテキスト ファイルを取得し、それを興味深い定数 (最初の文字、最後の文字、文字の幅と高さなど) を宣言する .cc/.h ファイルのペアに変換し、実際のデータを次のようにするものがあります。大 static const uint8_t[].

このようなことを C++ 自体で行おうとすると、最初のパスなしでコンパイル時にフォント データが自動生成されるため、手間がかかり、判読できなくなる可能性が高くなります。.o ファイルを手動で記述することは問題外です。方眼紙を切り出し、手作業でバイナリにエンコードし、すべてを入力するのも同様です。

私見ですが、コード ジェネレーターはこのようなことに適しています。 コンピュータはあなたのために機能するのではなく、その逆ではないことを決して忘れないでください。

ところで、発電機を使用する場合は、 いつもいつもいつもいつも 生成された各ファイルの先頭と末尾の両方に次のような行を含めます。

// This code was automatically generated from Font_foo.txt. DO NOT EDIT THIS FILE.
// If there's a bug, fix the font text file or the generator program, not this file.

私たちが使用するのは テロシス 私たちのプロジェクトのコードジェネレーター: http://www.telosys.org/

CRUD 画面やドキュメントなどの反復的なタスクの開発期間を短縮するために作成されました。

私たちにとって最も重要なことは、必要に応じて新しい生成ターゲットを作成したり、既存のテンプレートをカスタマイズしたりするために、ジェネレーターのテンプレートをカスタマイズできることです。そのため、テンプレート エディター (Velocity .vm ファイル用) も作成しました。Java/Spring/AngularJS コード ジェネレーターでは問題なく動作し、他のターゲット (PHP、C#、Python など) にも適応できます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top