ハードコーディング

ハードコーディング(ハードコーディングまたはハードコーディングとも呼ばれる) は、外部ソースからデータを取得したり、実行時にデータを生成したりするのではなく、プログラムまたはその他の実行可能オブジェクトのソースコードに直接データを埋め込むソフトウェア開発手法です。

ハードコードされたデータは、通常、ソース コードを編集して実行可能ファイルを再コンパイルすることによってのみ変更できますが、デバッガーまたは16 進エディターを使用してメモリ内またはディスク上で変更することもできます。

ハードコードされたデータは、物理定数、バージョン番号、静的テキスト要素 など、変更されない情報に最適です。

一方、ソフトコード データは、ユーザー入力、テキスト ファイル、INI ファイル、HTTP サーバー応答、構成ファイル、プリプロセッサ マクロ、外部定数、データベース、コマンド ライン引数を通じて任意の情報をエンコードし、実行時に決定されます。

ハードコーディングでは、入力データや希望するフォーマットが変わるたびにプログラムのソースコードを変更する必要があり、エンドユーザーにとってはプログラム外部の何らかの手段で詳細を変更する方が便利な場合があります。^[1]

ハードコーディングは多くの場合必要ですが、アンチパターンと見なすこともできます。^[2] プログラマーは、エンドユーザー向けの動的なユーザーインターフェイスソリューションを考案していない場合でも、機能を提供したりプログラムをリリースしたりする必要があります。これは通常一時的なものですが、短期的にはコードを提供するプレッシャーを解消します。その後、ソフトコーディングが行われ、ユーザーがパラメータを渡して、エンドユーザーが結果や成果を変更できるようになります。

「ハードコード」という用語は、当初は回路のハードワイヤリングのアナロジーとして使用され、ソフトウェアの設計と実装での使用から生じる柔軟性のなさを伝えることを意図していました。MUDなどの実行時に拡張可能な共同開発環境のコンテキストでは、ハードコーディングは、低レベルのタスクとスクリプトの実行を担当するシステムのコアエンジンの開発も指します。これは、テキストファイル、 INIファイル、プリプロセッサマクロ、外部定数、データベース、コマンドライン引数、HTTPサーバー応答、構成ファイル、ユーザー入力などの外部ソースからの値を使用して、実行時にシステムによって解釈される高レベルのスクリプトを開発するソフトコーディングとは対照的です。この場合、この用語は軽蔑的なものではなく、出力データを埋め込むことではなく、一般的な開発を指します。

資格情報をハードコードすることは、バックドアを作成する一般的な方法です。ハードコードされた資格情報は通常、構成ファイルやアカウント列挙コマンドの出力には表示されず、ユーザーが簡単に変更またはバイパスすることはできません。発見された場合、ユーザーは、ソースコードからプログラムを変更して再構築するか（ソースが公開されている場合）、ソフトウェアを逆コンパイルまたはリバースエンジニアリング するか、プログラムのバイナリコードを直接編集するか、整合性チェック（デジタル署名、改ざん防止、チート防止など）を導入して予期しないアクセスを防ぐことで、このようなバックドアを無効にできる可能性がありますが、このようなアクションはエンドユーザー使用許諾契約で禁止されていることがよくあります。

デジタル著作権管理対策として、ソフトウェア開発者は固有のシリアル番号をプログラムに直接ハードコードすることがあります。または、公開キーをハードコードして、キージェネレーターを作成することが不可能な DRM を作成することも一般的です。

反対の場合、ソフトウェアクラッカーは有効なシリアル番号をプログラムにハードコードしたり、実行ファイルがユーザーにシリアル番号を要求しないようにしたりして、有効な番号を入力しなくても不正なコピーを再配布できるようにし、ハードコードされているキーがあればすべてのコピーで同じキーを共有できるようにします。

Windows プログラムが常に C:\Program Files\Appname にインストールされると想定してプログラムされている場合、誰かがスペースや組織上の理由で別のドライブにインストールしようとすると、インストールに失敗するか、インストール後に実行できなくなる可能性があります。平均的なユーザーはデフォルトのドライブとディレクトリにインストールし、テストにはインストール ディレクトリを変更するオプションが含まれていない可能性があるため、この問題はテスト プロセスで特定されない可能性があります。ただし、デフォルトのインストール パスはオペレーティング システム、OS のバージョン、およびシステム管理者の決定によって異なるため、プログラマーと開発者はプログラムのインストール パスを固定しないことをお勧めします。たとえば、Microsoft Windowsの多くのインストールでは、ドライブ C: をプライマリハード ディスクとして使用しますが、これは保証されていません。

初期のコンピュータのマイクロプロセッサでも、メモリ内の固定アドレスから実行を開始するという同様の問題がありました。

一部の「コピー保護」プログラムは、起動時にフロッピー ディスクまたはフラッシュ ドライブ上の特定のファイルを検索し、不正なコピーではないことを確認します。コンピューターをフロッピー ドライブのない新しいマシンに交換した場合、フロッピー ディスクを挿入できないため、フロッピー ドライブを必要とするプログラムを実行できなくなります。

この最後の例は、ハードコーディングが当時は完全に機能するように見えても、結局は非実用的になる可能性がある理由を示しています。1980 年代と 1990 年代には、ほとんどの PC に少なくとも 1 つのフロッピー ドライブが搭載されていましたが、フロッピー ドライブは後に使用されなくなりました。15 年前にそのようにハードコーディングされたプログラムは、更新しないと問題が発生する可能性があります。

一部の Windows オペレーティング システムには、ハード ディスク上でファイルを論理的に整理する 特殊フォルダーと呼ばれるものがあります。ハード コーディングに関連して、次のような問題が発生する可能性があります。

一部の Windows プログラムでは、プロファイル パスを などの開発者定義の場所にハード コードします。これはWindows 2000以降のほとんどのシステムのパスですが、プロファイルがネットワーク上に保存されていたり、別の場所に保存されていたりすると、エラーが発生します。これを取得する適切な方法は、関数を呼び出すか、環境変数を解決することです。開発者がよく行うもう 1 つの想定は、プロファイルがローカル ハード ディスクにあると想定することです。 C:\Documents and Settings\UsernameGetUserProfileDirectory%userprofile%

一部の Windows プログラムでは、 へのパスMy Documentsが としてハードコードされていますProfilePath\My Documents。これらのプログラムは英語版を実行しているマシンでは動作しますが、ローカライズされたバージョンの Windows では、このフォルダーの名前は通常異なります。たとえば、イタリア語版では、フォルダーの名前はDocumentiMy Documentsです。Windows 2000 以降のグループ ポリシーのフォルダー リダイレクトを使用して再配置されている可能性もあります。これを取得する適切な方法は、関数を呼び出すことです。 My DocumentsSHGetFolderPath

プログラム内の「FileName」という変数などの間接参照は、「ファイルの参照」ダイアログ ウィンドウにアクセスすることで展開でき、ファイルが移動してもプログラム コードを変更する必要はありません。

ハードコーディングは、ソフトウェアを他の言語に翻訳する準備をする際に特に問題になります。

多くの場合、配列のサイズなど、ハードコードされた単一の値は、プログラムのソース コード内に複数回出現することがあります。これはマジック ナンバーになります。値の出現の一部が変更されたが、すべてが変更されていない場合、これは一般にプログラム バグの原因になります。このようなバグは見つけにくく、プログラム内に長期間残る可能性があります。 ハードコードされた同じ値が複数のパラメーター値に使用されている場合 (6 要素の配列と 6 の最小入力文字列長など) に、同様の問題が発生する可能性があります。プログラマーは、各インスタンスがどのように使用されているかをコードで確認せずに、値のすべてのインスタンスを誤って変更する可能性があります (多くの場合、エディターの検索と置換機能を使用)。両方の状況は、名前を値に関連付ける定数を定義し、コード内の出現ごとに定数の名前を使用することで回避できます。

ハードコーディングの重要な例の 1 つは、文字列がファイルに直接配置される場合です。この場合、翻訳者はプログラムを翻訳するためにソース コードを編集する必要があります。(gettext文字列をファイルに残したまま、ソース コードを変更せずに翻訳できる というツールがあります。これは、文字列のハードコーディングを効果的に解除します。)

国際情報オリンピックなどのコンピューティング競技では、参加者は問題の要件に従って特定の入出力パターンを持つプログラムを作成する必要があります。

まれに、入力可能な数が十分に少ない場合、参加者は、すべての入力可能なものを正しい出力にマッピングするアプローチの使用を検討することがあります。このプログラムは、アルゴリズムによるソリューションではなく、ハードコードされたソリューションと見なされます(ハードコードされたプログラムは、アルゴリズム プログラムの出力である可能性がありますが)。

ソフトコーディングは、テキスト ファイル、INI ファイル、プリプロセッサマクロ、外部定数、構成ファイル、コマンド ライン引数、データベース、ユーザー入力、HTTP サーバー応答などの外部リソースから値や関数を取得することを指すコンピューター コーディング用語です。これは、ソース コードに値や関数をコーディングすることを指す ハードコーディングの反対です。

頻繁に変更される値のハードコーディングを避けることは、プログラミングの良い習慣です。ソフトウェアのユーザーは、プログラムのソースコードを編集することなく、合理的な範囲内でニーズに合わせてカスタマイズできる必要があります。同様に、注意深いプログラマーは、コード内のマジックナンバーを避けて、読みやすさを向上させ、メンテナンスを容易にします。これらの習慣は、通常、ソフトコーディングとは呼ばれません。

この用語は、一般的にソフトコーディングがアンチパターンになる場合に使用されます。あまりに多くの値や機能を抽象化すると、必要に応じてコードを変更する場合よりも複雑になり、メンテナンスの問題が発生する可能性があります。この意味でのソフトコーディングは、 The Daily WTFの記事で取り上げられました。^[3]

極端な場合、ソフトコードされたプログラムは、設計や実装が不十分な独自のスクリプト言語や、編集に高度なプログラミング スキルを必要とする構成ファイルを作成します。これにより、元のプログラムの構成を支援するユーティリティが作成されることがあり、これらのユーティリティ自体が「ソフトコード」化されることがよくあります。

適切な構成可能性と問題のあるソフトコーディングの境界は、プログラムのスタイルと性質によって変わります。クローズドソース プログラムは、エンド ユーザーがソースにアクセスして変更を加えることができないため、非常に構成可能である必要があります。社内ソフトウェアや配布が制限されているソフトウェアは、変更されたコピーを配布する方が簡単なため、構成可能性が低くなる場合があります。カスタム ビルドの Web アプリケーションは、スクリプトの変更が構成ファイルの変更よりも難しいことはほとんどないため、構成可能性が制限されている方が適していることがよくあります。

ソフトコーディングを回避するには、提供する追加の柔軟性がエンドユーザーにとってどのような価値をもたらすかを考慮し、追加された構成可能性に伴う複雑さの増加や関連する継続的なメンテナンス コストと比較します。

ソフトコーディングが提供しようとしている柔軟性を実現するための正当な設計パターンはいくつか存在します。構成ファイルに適さない柔軟性を必要とするアプリケーションでは、スクリプト言語を組み込むことでメリットが得られる場合があります。多くの場合、適切な設計は、確立されたスクリプト言語に統合されたドメイン固有言語です。もう 1 つのアプローチは、アプリケーションの機能のほとんどをライブラリに移動し、書き込み関連のアプリケーションを迅速に作成するための API を提供することです。

• クローズドソースソフトウェア
• ファームウェア
• 内部プラットフォーム効果
• 最小力の法則
• 自己修正コード