インターフェイスとそのインターフェイスを実装するいくつかのクラスのソース コードを生成するツールに取り組んでいます。私の出力は特に複雑ではないので、出力を通常のコード形式の標準に準拠させることは難しくありません。
しかし、これは私に考えさせました:自動生成されたコードは人間が読める程度である必要がありますか? 生成されたコードを人間が簡単に読み取って理解できるようにするために、いつ余分な努力を払う必要がありますか?
私の場合、生成しているクラスは基本的に、ビルドの別の部分に関連するデータのコンテナであり、データを取得するメソッドを備えています。クラス自体のコードを見る必要はありません。クラスが提供するさまざまな getter を呼び出すだけで済みます。したがって、コードが「クリーン」で、適切にフォーマットされていて、人間が簡単に読み取れるかどうかは、おそらくそれほど重要ではありません。
しかし、単純なロジックが少量以上含まれるコードを生成するとどうなるでしょうか?
生成されたコードが読みやすく、通常のコーディング スタイルに従っていることも同様に重要だと思います。ある時点で、誰かがコードをデバッグするか、「舞台裏」で何が起こっているかを確認する必要があります。
そのとおり！; 人間が自動生成されたコードを簡単に読めることが重要である理由を説明するために、ストーリーを挿入することもできます...
私はかつて、新しいプロジェクトに取り組む機会を得ました。さて、コードの記述を開始するときに最初に行う必要があることの 1 つは、データベースとの間で何らかの接続とデータ表現を作成することです。しかし、このコードを手で書くだけでなく、データベース スキーマから基本クラスを自動的に構築する独自のコード ジェネレーターを開発した人がいました。それは本当にすてきでした。このコードをすべて書くという退屈な仕事は、今や私たちの手から離れました.唯一の問題は、生成されたコードが普通の人間には読めないということでした.
もちろん、私たちはそれについては考えていませんでした。しかし、しばらくすると問題が発生し始め、データがユーザー入力から誤って読み取られ (またはそう思った)、読み取りだけを行っている間にデータベース内で破損が発生しました。奇妙な..読み取りはデータを変更しないため(繰り返しますが、私たちは考えました)...
優れた開発者のように、私たちは自分たちのコードに疑問を持ち始めましたが、何日も検索した後..コードを書き直しても何も見つかりませんでした...そして、自動生成されたコードが壊れていることに気付きました!
そのため、さらに大きなタスクが私たちを待っていました。自動生成されたコードをチェックすることで、まともな人が合理的な時間で理解することはできませんでした...私は、発音できない変数と関数名を持つ、インデントされていない、本当に悪いスタイルのコードについて話している...コードが実際にどのように機能するかを理解しようとするよりも、自分でコードを書き直した方がより高速であることが判明しました。
最終的に、コード ジェネレーターを作成した開発者が後でそれを作り直したので、以前のように問題が発生した場合に備えて、読み取り可能なコードが生成されるようになりました。
これは、当面のトピックについて見つけたばかりのリンクです。私は実際に、 「実用的なプログラマー」の本の章の 1 つへのリンクを探して、コードを最初に調べた理由を指摘しました。
それは、生成されたコードがどのように使用されるかによると思います。コードが人間に読まれることを意図していない場合、つまり、何かが変更されるたびにコードが再生成される場合は、可読である必要はないと思います。ただし、「通常の」プログラミングの中間ステップとしてコード生成を使用している場合、生成されたコードは残りのソース コードと同じ可読性を持つ必要があります。
実際、生成されたコードを「判読不能」にすることは、人々が生成されたコードを「ハッキング」するのを思いとどまらせ、代わりにコードジェネレーターで変更を実装することを思いとどまらせるため、利点になる可能性があります。これは、コードを再生成する必要があるときはいつでも非常に便利です。何らかの理由で、生成されたコードが「終了」したと思ったために同僚が行った変更を失うことはありません。
はい、そうです。まず、デバッグする必要があるかもしれません -- 自分で簡単にできるようになります。第二に、いつの日かコードを手動で変更する必要があり、人間のコードになる可能性があるため、ショップで使用するコーディング規則に準拠する必要があります。このシナリオは通常、コード生成ツールが必要な特定のものをカバーしておらず、その目的のためだけにツールを変更する価値がないと見なされる場合に発生します。
言及されなかった問題のもう1つの側面は、生成されたコードも「バージョン管理に適した」ものでなければならないということです（実行可能な限り）。
生成されたコードとソースコードの差分を再確認することは、何度も役立つことがわかりました。
そうすれば、コードを生成するツールのバグをときどき見つけることができます。
あなたのコード生成ツールが優れたデバッガーを持っていない限り、コードは人間が読めるものであることが不可欠であると私は言います.システムで。「UML からのコード」への私自身の遠足は、おそらく「派手な」デバッグプロセスを理解することができなかったので、私の口に苦味を残しました。
独自に生成されたコードをデバッグする必要がある場合は、自殺することになります。 できないと思い始めないでください。 コードを信頼してコードを生成する場合、システムに 2 つのエラーが既に導入されていることに注意してください。つまり、自分自身を 2 回挿入したことになります。
人間が解析可能にしない理由は絶対にありません。
-アダム
生成されたコードの要点は、高水準言語でより簡単に定義できる「複雑な」ことを行うことです。生成されるため、この生成されたコードの実際のメンテナンスは、生成されたコードではなく、コードを生成するサブルーチン内で行う必要があります。
したがって、人間の可読性は優先度を低くする必要があります。実行速度や機能性などのほうがはるかに重要です。これは特に、生成されたコードを使用して高速なルックアップ テーブルを事前に生成し、パターン マッチングを行う bison や flex などのツールに注目する場合に当てはまります。
コードがコンパイラによってのみ読み取られるのか、人間によっても読み取られるのかによって異なります。さらに、コードが超高速であると想定されているかどうか、または読みやすさが重要であるかどうかも重要です。疑わしい場合は、読み取り可能なコードを生成するために余分な努力を払ってください。
ここにいるほぼ全員と同じように、私はそれを読みやすいものにすると言います。生成プロセスに余分な費用はかからず、あなた (またはあなたの後継者) が発掘に行くときに感謝するでしょう。
実際の例については、Visual Studio が生成するものを見てください。コメントとすべてを含む、適切にフォーマットされています。
生成されたコードはコードであり、どのコードも読み取り可能で適切にフォーマットされていてはならないという理由はありません。これは、生成されたコードでは特に安価です。フォーマットを自分で適用する必要はありません。ジェネレーターが毎回それを行います! :)
あなたが本当に怠惰な場合の二次的なオプションとして、少なくともある程度の一貫性を確保するために、コードをディスクに書き込む前に、選択した美化ユーティリティを介してコードをパイプすることはどうですか。それにもかかわらず、私が知っているほとんどすべての優れたプログラマーは、コードをかなり衒学的にフォーマットしています。それには十分な理由があります。
将来誰かがあなたのコードが何をするかを調べて見たいと思う可能性は十分にあります。そのため、ある程度わかりやすくすることは良いことです。
生成された各ファイルの先頭に、このファイルが生成された方法と理由、およびその目的を示すコメントを含めることもできます。
一般に、後で人間が変更する必要があるコードを生成する場合は、可能な限り人間が判読できるようにする必要があります。ただし、生成されて二度と触れられないコードであっても、(コード ジェネレーターを作成する開発者として) ジェネレーターをデバッグできるように、十分に読み取り可能である必要があります。わかりにくい場合は追跡します。
デバッグを容易にするためだけに、人間が読めるようにするために余分な時間を費やす価値があると思います。
生成されたコードは読み取り可能である必要があります (フォーマットなどは通常、まともな IDE で処理できます)。コードの有効期間のある段階で、誰かがそれを見て、意味を理解したいと思うでしょう。
非常に単純な仕組みのデータ コンテナやオブジェクトの場合、人間が読みやすいかどうかはあまり重要ではないと思います。
ただし、開発者が何かがどのように発生するかを理解するためにコードを読まなければならなくなるとすぐに、コードは読み取り可能である必要があります。ロジックにバグがある場合はどうなりますか? 誰もコードを読んで理解できない場合、どうやってそれを発見するのでしょうか? 意図を表現するために、より複雑なロジック セクションのコメントを生成するところまで行きます。これにより、本当にバグがあるかどうかを判断しやすくなります。
ロジックは常に読み取り可能である必要があります。他の誰かがコードを読む場合は、その場所に身を置くようにして、特定のコード部分を読まなくても、高レベル (および低レベル) のコードを完全に理解できるかどうかを確認してください。
決して読み取られることのないコードにあまり時間をかけたくありませんが、時間があまりない場合は、生成されたコードを調べます。そうでない場合は、少なくとも読みやすさの損失をカバーするコメントを作成してください。
このコードがデバッグされる可能性が高い場合は、人間が読める形式でコードを生成することを真剣に検討する必要があります。
生成されるコードにはさまざまなタイプがありますが、最も単純なタイプは次のとおりです。
後者を作成している場合は、コードを人間が読めるようにする必要があります。
クラスとインターフェイスは、開発者にとってどれだけ「立ち入り禁止」であるべきだと考えていても、ほぼ確実に生成コード タイプ 2 に分類されます。これらは、デバッガーによって別の時点でヒットされます。コードのフォーマットを適用することは、少なくともコンパイラがこれらの生成されたクラスにヒットしたときのデバッグプロセスを簡単にすることができます
すでに上で述べた多くの正当な理由から、絶対にそうです。もう 1 つは、(安全性と信頼性の問題のために) 評価者によるコードのチェックが必要な場合、コードが人間による再実行可能であれば、かなり優れているということです。そうでない場合、評価者はそれを評価することを拒否し、あなたのプロジェクトは当局によって却下されます。唯一の解決策は、評価することです...コードジェネレーター（通常ははるかに困難です;））
答えは、場合によると思います。
*生成されたコードをアーティファクトとして構成および保存する必要があるかどうかによって異なります。たとえば、c コンパイラからのオブジェクト コード出力を保持したり構成したりすることはほとんどありません。なぜなら、いつでもソースから再現できることを知っているからです。ここにも同様の類推があるのではないかと思います。*これは、Misra-C や DO178 などの標準に対してコードを認証する必要があるかどうかによって異なります。*コードがコンパイルされるたびにツールを介してソースが生成されるか、後でビルドに含めるためにソースが保存されるかによって異なります。
個人的には、コードをビルドし、それを実行可能ファイルにコンパイルしてから、中間コードを破棄することだけが必要な場合は、コードをきれいにしすぎても意味がありません。