最近 Sourcery というOSSを使ってSwiftメタプロしてます。
色々使っていると、生成ファイルの一番上に // DO NOT EDIT と書いてあるのを発見しました。そこで、
「自動生成のコードって編集しちゃだめなんだっけ？...そういえば達人プログラマーにコードジェネレーターの章があったな...。読み返そう！」
と思ったので読み直してみたところ、「ソースコードジェネレーターは2種類ある」と記述されていました。
今回はこれについてまとめていきます。
結論を先に言うと、**「(たぶん)自動生成のコードは編集して良い」 **です。
消極的なコードジェネレーター
目的
タイピング量を削減する。
解決策
パラメーター化されたテンプレートで、入力の組みから指定通りの出力を生成する。
生成コードとコードジェネレーターの関係
成果物を作り出すために一度だけ実行するもの
それ以降、生成コードはコードジェネレーターから独立する。
生成後の扱い
一人前のソースファイルになり、編集、コンパイルされ、ソース管理の対象にもなる。
特徴
完全に正しいものを作る必要がない。精度が100%でなくとも、
(出力を修正するコスト + コードジェネレータに費やした時間) < (普通に書く時のコスト)
が成立していれば良い
積極的なコードジェネレーター
目的
利便性を追求する。
解決策
元となる唯一の知識を読み込み、アプリケーションが必要とするさまざまな形式に変換する。
生成コードとコードジェネレーターの関係
結果が必要となるたびに実行する。
必要に応じて何度もコードジェネレーターを用いて、結果を再生成しなおす。
生成後の扱い
変換された形式は使い捨て。
例
データベーススキーマの変更に合わせて、対応するソースコードを再生成する。
(iOSなら依存性自動解決してくれるDIライブラリのDIKitが思い当たった)
振り返り
ここまでを見ていくと**「自動生成のコードを編集する」**という使い方は、消極的なコードジェネレーターに当てはまる事が分かりました。
// DO NOT EDIT と書いてあったのは、作者が 積極的なコードジェネレーター のみをイメージして作成したからかもしれません。
作者の意図とは異なるかもしれないのですが、 「構文解析→メタプロの組み合わせでタイピング量が更に減らせるなら積極的に使っていこう！」と楽観的に捉えています。
あと達人プログラマーは素晴らしい本なのでオススメです！