データ値をプログラムにハードコーディングする利点はありますか？
私は独学で初心者のコーダーなので、プログラマーの専門用語を使用しないと申し訳ありません。
データのクエリからレポートを生成するツールを基本的に作成する開発者に、継続的に更新されるデータを提供するプロジェクトに取り組んでいます。
関係者全員が、データ値（スキーマではなくドメイン/値自体）をレポート生成プログラムにハードコーディングする必要があると考えているようです。
たとえば、担当者について報告していたとします。レポートはカテゴリに分割され、各部門に見出しが付けられます。各部門の見出しの下には、役職の小見出しが表示され、各小見出しの下には従業員のリストが表示されます。開発者は、部門と役職をハードコーディングしたいと考えています。一方、実行時にそれらのクエリを実行し、レコードをソートして、そこにある値に基づいてレポートヘッダーを動的に生成できると思います。
潜在的な値のリストは時間の経過とともに変化するため（たとえば、部門が作成されたり名前が変更されたり、新しい役職が追加されたり）、コードを継続的に更新する必要があります。コードのメンテナンス手順をスキップして、レポートを動的に整理できるように思えます。
私は開発者ではないので、何が足りないのでしょうか。このようなツールに値をハードコーディングすることにはどのような利点がありますか？これは通常、プログラムの設計方法ですか？
ウィキペディア：
ハードコーディング（ハードコーディングまたはハードコーディング）とは、おそらく振り返ってみれば、プログラムまたはその他の実行可能オブジェクトのソースコードに直接入力データまたは構成データと見なされるもの、または外部ソースからデータを取得したり、指定された入力を使用してプログラム自体でデータまたはフォーマットを生成したりする代わりに、データ。
ハードコーディングはアンチパターンと見なされます。
アンチパターンと見なされるハードコーディングでは、入力データや目的の形式が変更されるたびにプログラムのソースコードを変更する必要があります。エンドユーザーにとって、プログラムの外部で何らかの方法で詳細を変更する方が便利な場合があります。
時々それを避けることができないがそれは一時的であるべきです。
多くの場合、ハードコーディングが必要です。プログラマーは、エンドユーザー向けの動的なユーザーインターフェイスソリューションがない場合でも、機能を提供するか、プログラムをリリースする必要があります。これは通常一時的なものですが、短期的には、コードを提供するというプレッシャーを解決します。その後、ユーザーが結果または結果を変更する方法をエンドユーザーに提供するパラメーターを渡すことができるように、ソフトコーディングが行われます。
- メッセージをハードコーディングすると、プログラムの国際化が難しくなります。
- パスをハードコーディングすると、別の場所に適応することが難しくなります。
ハードコーディングの唯一の利点は、コードの高速配信にあるようです。
本当に？可能な有効なユースケースはありませんか？
hard-coding は一般的に anti-pattern であるか、少なくとも非常に悪い code smell であることに同意しますが、多くの場合、理にかなっている：
- 単純化（ [〜＃〜] yagni [〜＃〜] ）、
- 入力は実際には一定であり、決して変化しません（つまり、自然またはビジネスの定数または1の近似値を表します。たとえば、0、PIなど）。
- 組み込みソフトウェア（メモリと割り当ての制約が頭に浮かぶ）、
- 安全なソフトウェア（これらの値は利用可能ではなく、解読やリバースエンジニアリングが容易ではありません（暗号トークンやソルトなど））。
- 生成されたコード（プリプロセッサーまたはジェネレーターは構成可能ですが、ハードコードされた値でコードを吐き出します）、
- そしておそらくもう少し。
まだ アンチパターン ？そうです Over-Engineering ！それはあなたのソフトウェアの平均余命についてです!!
すべての大きな理由があると言っているわけではありません。一般的に、ハードコードされた値を使用します。しかし、正当な理由で簡単にパスを取得できる人もいます。
そして、単純さについて最初の1つを監督しないでください/ [〜＃〜] yagni [〜＃〜] それを些細なことと考えてください：単純なもののためにクレイジーなパーサーと値チェッカーを実装する理由はおそらくありません狭いユースケースで1つのジョブを非常にうまく実行するスクリプト。
バランスを見つけるのは難しいです。場合によっては、ソフトウェアが当初の単純なスクリプトよりも成長して長持ちすることを予測できません。しかし、多くの場合、それはその逆です。私たちは物事を過剰に設計し、プロジェクトはPragmatic Programmerを読むよりも早く棚上げされます。初期のプロトタイプが必要としなかったものよりも、時間と労力を無駄にしました。
それがアンチパターンの平均的なことです。アンチパターンはスペクトルの両極端に存在し、それらの外観はコードをレビューする人の感度に依存します。
値をハードコードしても問題ない場合があります。たとえば、アルゴリズムの目的で特定の値である必要があるビットマスクには、0や1つまたはさまざまなn ^ 2-1値などのいくつかの数値があります。そのような値を構成可能変数に許可することには価値がなく、問題の可能性を開くだけです。つまり、値を変更しても問題が発生しない場合は、おそらくハードコーディングする必要があります。
あなたが与えた例では、ハードコーディングがどこで役立つかわかりません。あなたが言及するものはすべて、見出しを含めてすでにデータベースにあるはずです。プレゼンテーションを駆動するもの（並べ替え順など）も、そこになければ追加できます。