データ値をプログラムにハードコーディングする利点はありますか？

私は独学で初心者っぽいコーダーなので、プログラマーの専門用語に釘付けにならなければ謝罪します。

私は、データのクエリからレポートを生成するツールを本質的に作成する開発者に継続的に更新されるデータを提供するプロジェクトに取り組んでいます。

関係者全員が、データ値（スキーマではなく、ドメイン/値自体）をレポート生成プログラムにハードコーディングする必要があると考えているようです。

たとえば、人員について報告しているとします。レポートは各部門の見出しを持つカテゴリに分割され、各部門の見出しの下に役職の小見出しが表示され、各小見出しの下に従業員のリストが表示されます。開発者は、部門と役職をハードコーディングしたいと考えています。一方、実行時にそれらをクエリし、レコードでソートし、そこにある値に基づいてレポートヘッダーを動的に生成できると思います。

潜在的な値のリストは時間とともに変化するため（たとえば、部門の作成/名前の変更、新しい役職の追加など）、コードを継続的に更新する必要があります。私は、コードのメンテナンス手順をスキップして、レポートを動的に整理できるように思えます。

私は開発者ではないので、何が欠けているのだろうと思っています。このようなツールに値をハードコーディングするとどのような利点がありますか？これは通常、プログラムの設計方法ですか？

ウィキペディア：

ハードコーディング（ハードコーディングまたはハードコーディング）は、おそらく振り返ってみるだけで、入力データまたは構成データと見なされるものをプログラムまたはその他の実行可能オブジェクトのソースコードに直接埋め込むソフトウェア開発プラクティス、またはデータを外部ソースから取得したり、データを生成したり、指定された入力でプログラム自体をフォーマットしたりする代わりに。

ハードコーディングはアンチパターンと見なされます。

アンチパターンと見なされ、ハードコーディングでは、エンドユーザーにとってプログラム外の手段で詳細を変更する方が便利な場合、入力データまたは目的の形式が変更されるたびにプログラムのソースコードを変更する必要があります。

回避できない場合もありますが、一時的なものである必要があります。

多くの場合、ハードコーディングが必要です。プログラマーは、エンドユーザーが解決するための動的なユーザーインターフェースソリューションを持っていないかもしれませんが、機能を提供するか、プログラムをリリースする必要があります。これは通常一時的なものですが、短期的にはコードを配信するプレッシャーを解決します。後で、ユーザーが結果または結果を変更する方法をエンドユーザーに与えるパラメーターを渡すことができるように、ソフトコーディングが行われます。

• メッセージをハードコーディングすると、プログラムの国際化が難しくなります。
• パスをハードコーディングすると、別の場所への適応が困難になります。

ハードコーディングの唯一の利点は、コードの高速配信であると思われます。

本当に？有効なユースケースはありませんか？

ハードコーディングは一般にアンチパターンまたは少なくとも非常に悪いコード臭であることに同意しますが、それが理にかなっているケースはたくさんあります。

• シンプルさ（YAGNI）、
• 入力は実際には一定であり、変化することはありません（つまり、自然定数またはビジネス定数、または1の近似値を表します。たとえば、0、PI、...）、
• 組み込みソフトウェア（メモリと割り当ての制約が頭に浮かぶ）、
• セキュリティで保護されたソフトウェア（これらの値は利用できず、暗号化トークンやソルトなどのデコードやリバースエンジニアリングが容易ではありません）
• 生成されたコード（プリプロセッサまたはジェネレータは構成可能ですが、ハードコードされた値でコードを吐き出します）
• そしておそらくもう少し。

まだアンチパターン？そうである以上、エンジニアリング！それはあなたのソフトウェアの平均寿命についてです!!

すべての大きな理由があると言っているわけではなく、一般的にはハードコーディングされた値に挑戦します。しかし、正当な理由で簡単にパスを取得できる人もいます。

そして、単純さ/ YAGNIに関する最初の1つを些細なことだと考えて監視しないでください。狭いユースケースで1つの仕事を非常にうまくこなす単純なスクリプトに、クレイジーなパーサーと値チェッカーを実装する理由はおそらくないでしょう。

バランスを見つけるのは難しいです。ソフトウェアが成長し、それが開始された単純なスクリプトよりも長く続くことを予見しない場合があります。しかし多くの場合、それは他の方法です：私たちは物事を過剰に設計し、あなたはプラグマティックプログラマーを読むことができるよりも速くプロジェクトを棚上げします。初期のプロトタイプでは必要なかったものよりも、時間と労力を無駄にしました。

それはアンチパターンの平均的なものです。それらはスペクトルの両極端に存在し、その外観はコードをレビューする人の感度に依存します。

値をハードコードしてもかまいません。たとえば、0のようないくつかの数値、またはアルゴリズム目的のために特定の値である必要があるビットマスクの1つまたはさまざまなn ^ 2-1値があります。そのような値を構成可能に許可することは価値がなく、問題の可能性を開くだけです。つまり、値を変更しても問題が発生するだけであれば、おそらくハードコーディングする必要があります。

あなたが与えた例では、ハードコーディングがどこで役立つかわかりません。あなたが言及するものはすべて、見出しを含めてすでにデータベースにあるはずです。プレゼンテーションを駆動するもの（ソート順など）が存在しない場合でも追加できます。

ハードコードされている可能性のある値をエンドユーザーが代わりに構成できるようにする堅牢なソリューションを実装するには、それらの値の堅牢な検証が必要です。彼らは空の文字列を入れましたか？彼らはそれが数字であるはずだった場所に非数字を入れましたか？SQLインジェクションを行っていますか？等。

ハードコーディングはこれらのリスクの多くを回避します。

それは、ハードコーディングが常に、あるいは頻繁に、良いアイデアであると言うことではありません。これは、考慮すべき要素の1つにすぎません。