生成されたコードのクリーンアップ：リファクタリングまたはマップ？

環境：

最近、XSD.exeによって生成されたクラスファイルを処理する必要がありました。ばかばかしく冗長なクラス/変数名（someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd一見するとと比較するのは難しいと思いますsomeRidiculouslyLongPrefixThenMaybeOneOtherThingChanged）と注釈がいたるところにあり、長さが3500行でした。結論として、一体何が起こっているのかを理解するのに私は年齢を重ねました。私はそれを読んで、自分の名前を何かの隣に置くことは決してないと思ったので...

質問：

1）生成されたコードをいじる（つまり、クリーンにする）ことは悪い習慣ですか。

2）生成されたクラスを自分の素敵でクリーンなクラスにマップするマッパーを作成することをお勧めします（これで、とても楽しく作業できます）。

編集：

すべてのコメントをありがとう。

実際に何か面白いことをするつもりだった場合（つまり、トランスポートオブジェクト以外のドメインオブジェクトがあった場合）、それらを「よりクリーンな」クラスにマップすると思います。それらのうちの一種の機能。この場合、クラスは事実上DTOであるため、おそらく名前が対応する要素と一致することは理にかなっています。述べたように、私はそれに触れる必要はありません-処理のためにデータを別のレイヤーに渡す前に、アクセサー/ミューテーターを呼び出すだけです。

今のところ、私はそれらを一人にしておくと思います。

生成されたコードをリファクタリングして整理して整理することの危険性は、自分または別の開発者がツールによって再度生成された場合、変更が失われることです。

あなたのチームは、別のファイルでコードを生成し、それをクリーンなバージョンにコピーし、リファクタリングを行って変更を適用するだけの時間とリソースを必要とする位置にいる可能性があります。（私はEntity Frameworkのオリジナルバージョンを使用してきました。）

生成された名前を使用できない場合は、生成元を変更するか、＃2で提案されているようにしてください。

原則として、生成されたコードには触れないでください。これを行うと、二度と生成されないことを約束することになります。そうしないと、行ったすべての変更をやり直す必要があります。生成されたコードをより見栄えよくしたい場合は、コード生成とクリーンアップの両方を自動化する必要があります。たとえば、XMLファイルをどこかに生成する場合xmlindent、ビルドプロセスの一部として実行することができます。

同様の理由で、生成されたコードはソース管理に属しません。データとルールをソース管理下に置き、ビルドスクリプトにコード生成を処理させます。

生成されたコードへの変更は、コードジェネレーターを通過する必要があります。つまり、生成されたコードの外観を変える場合は、コードジェネレーターの入力、コードジェネレーター自体を変更するか、スクリプト可能な後処理を適用します。ただし、手動で編集しないでください。

例外は「足場」スタイルのコードジェネレーターです。ジェネレーターを1回実行すると、さらに構築するためのスケルトンが提供されます。これらを使用すると、同じファイルに対してジェネレータを再度実行することはないため、生成されたファイルを通常のソースファイルとして扱い、ジェネレータからのものであることを忘れます。

@NikolaiDante（+1）の回答に完全に同意します。

dotnet / c＃には、「部分クラス」の概念があります。「使用するクラス」のソースコードは、生成された部分と手動で追加/編集された部分の2つの個別のファイルで構成されます。APIの美化は、コードジェネレーターによって上書きされない「手動」ファイルに組み込まれます。

java / hybrisの世界では、none-generated-codeの継承を使用します。

たとえば、「GeneratedCustomer」から継承した「api-beautifications」を持つクラスCustomerがあります。