coding-style - ハードコーディングに対するあなたの態度はどうですか？

Question

私のはこれです：

ハードコーディングがその方法です！私の問題はすべてなくなります。1つずつコーディングするだけです。そして、問題が戻ってきてあなたの一日を殺します。

私は絶対に嫌いでしたが、実際には「ビジネスマン」は欲しいものを手に入れるのに時間がかからないのでそれを好む傾向があります。そして、特に企業環境で働くソフトウェア開発者として、ほとんどの人は「ええ、なぜわざわざ、それをハードコーディングするだけです」と言うでしょう。ハードコーディングに対するあなたの態度はどうですか？

score 21 · Accepted Answer

ハードコーディングは、できるだけ避けるべきものです。

コードに何かをハードコーディングすると、コードの移植性が大幅に「破壊」されます。プラットフォームに依存しない言語であっても、「一度コンパイルすればどこでも実行できる」とは言えません。それは良いソフトウェアエンジニアリングの実践ではないので、ハードコードを避ける方が良いと思います。

しかし、場合によっては、特にコードをデバッグする際に、それが必要になることも知っています。私が提案する方法は次のとおりです。最初にハードコードを使用してコードを開発し、安定させてからハードコードを削除します...

また、セキュリティ上の懸念などにより、ハードコーディングが必要になる場合もあります:)。攻撃面を増やす可能性があるため、レジストリ、構成ファイルなどの使用が許可されない場合があります。しかし、それはまれなケースだと思います。

score 21 · Accepted Answer

IT に特効薬は存在しません。

賢いならそうする。
馬鹿ならやらない。

ばかげたことをするように誰かに言われたら、メールスレッドを保存して JOB を保存します

score 14 · Accepted Answer

正しい理由で正しく行われていれば、ハードコーディングに問題はありません。

「正しく行う」とは、すべてのハードコーディングを 1 つまたは 2 つのモジュールに集中させることを意味します。

Cの場合、Javaのcodes.hのすべての値を定義すると、パブリック定数でいっぱいのcodes.javaクラスがあります。

ハードコーディングにはいくつかの「正当な理由」があります。

シンプルさ。
サポート - 値が外部構成ファイルにある場合、愚かな構成から身を守ることはできず、すべての可能な構成をテストすることはできません。ハードコードされている場合、何を扱っているかがわかります。
パフォーマンス。
読みやすさ。編集セッションで知っておくべきことをすべて見ることができます!

複雑な構成ファイルを避けるべきいくつかの理由もあります。十分なパラメーターとオプションがある場合、あまり良くない言語でプログラミングすることになります。

score 8 · Accepted Answer

概念的には、あまりハードコーディングは好きではありません。

しかし実際には、いくつかの値をハードコーディングする傾向があります。ハードコーディングする主な理由は次のとおりです。

仕様では、正確にこの値が必要であり、変更すべきではありません。変更可能にすると、ソフトウェアが不安定になる可能性があります。
値はおそらく後で変更される可能性がありますが、誰がどのように変更したかがわからないため、どこに属しているかわかりません。構成ファイル、リソースファイル、データベース、レジストリ、またはその他の場所に属している可能性があります。間違った場所に置くことは、ハードコーディングするよりも悪いことです。

オーバーエンジニアリングではないと思う「ハードコーディングのベストプラクティス」がいくつかあります。

ハードコーディングされた値は、常に定数の中央の場所で宣言する必要があります。
値がハードコードされている場合でも、コンポーネントに引数として渡す必要があります。コンポーネントは、値がどこから来るかを気にする必要はありません。コンポーネントを再利用可能にします。

これにより、ハードコーディングされた値を後で別の場所に移動できます。

score 4 · Accepted Answer

私の初期の頃にハードコーディングの経験があった人として（誰にも言わないでください）、それが戻ってきてあなたを悩ませると自信を持って言えます。私が作成したこのアプリケーション (これについては今は説明しません)があり、ハードコードされたコンテンツがたくさんあったため、完全に書き直さなければなりませんでした。それは1998年にさかのぼります。

将来そのクライアントをサポートしたくない場合を除き、これを行わないでください。今節約できる時間は、後で修理に費やす時間になります。

score 4 · Accepted Answer

組み込みおよび重要なソフトウェアでは、ハードコーディングには 2 つの主な利点があります。

それはより速いです
それはより簡単です

これは、CPU負荷が少ない、つまり電力消費が少ない、動的メモリ割り当てが少ないかまったくない、アルゴリズムの複雑さが少ない、つまりデバッグが容易になるなどを意味します...

通常、ハードコードされたデータは、保守性を高めるために 1 つのヘッダーファイルに入れられます。

さらに、データベースからこのヘッダーファイルを自動生成することにより、柔軟性が提供されます。

score 2 · Accepted Answer

デフォルト値をハードコーディングすることは、構成可能である必要があるかもしれないすべてのものを実行する方法だと思います。

GUIコード（クライアントサーバー）では、3段階のルックアップを使用します。設定インスタンスにデフォルト値の設定を要求します。ただし、この渡されたデフォルト値は、構成ファイルが存在する場合はそれによって上書きされます。

そうすれば、後で2つのオプションがあります。お客様が別の何かを望んでいる場合は、構成ファイルで変更できます。また、設定ダイアログを構成して、ユーザーが構成できるようにすることもできます。

そのため、事実上、構成によってオーバーライドできるハードコードがあり、ユーザー設定によってオーバーライドできます。

唯一の問題は、すべての設定キーを文書化することです...

score 2 · Accepted Answer

通常、コードを最初に作成するよりも、コードの保守に多くの時間とお金が費やされます。コードに費やされる合計の80％は、通常、メンテナンス期間中に費やされます。したがって、メンテナンスを困難にするものはすべて、最初に正しく行うよりも最終的にはコストがかかります。ハードコーディングは間違いなくメンテナンスを困難にする1つのことであり、その結果、悪い考えです。

score 1 · Accepted Answer

ハードコーディングは行くべき道です！

しかし、Anthony が述べたように、構成可能な値を独自のクラスに入れました。このようにして、コンパイル時に構成できますが、構成用の外部 xml/txt ファイルを使用することに伴う複雑さはありません。

絶対に必要な場合にのみ、構成に xml/txt ファイルを使用します。それ以外の場合は、ハードコーディングよりも悪くない場合でも、オーバーエンジニアリングを行っているだけです。言うまでもなく、クライアントにまったく変更してほしくない設定ファイルがたくさんあります。

クライアントごとに異なる構成が必要な場合は、問題ありません。ハードコードされた値を独自のアセンブリ/dll に配置し、クライアントごとに異なる構成アセンブリを展開します。

Ayendeが言うように、すべてをハードコーディングすることが変化を可能にする鍵です。

score 0 · Accepted Answer

12文字を指す必要がある場合は、常に1になるため、char *安全に書き込むmalloc(12)ことができます。12整数を指す必要がある場合は、を書き込みます。sizeof(char)int *malloc(12 * sizeof(int))

絶対に、確実に 決して変わらないいくつかのものをハードコーディングします。それ以外の場合は、さらに2秒かかるので、先に進んで実行してみませんか？

score 0 · Accepted Answer

ハードコーディングが正しく行われている場合、それはボーナスになる可能性があります。たとえば、動的割り当てを行う代わりに配列サイズをハードコーディングした場合、配列がメモリ内のどこにあるかを正確に把握しているため、デバッグが容易になります。これは、あなたが実際にこれらのようなことを知りたいと思っていることを前提としています。

score 0 · Accepted Answer

彼らが望んでいたものを手に入れるのに時間がかかりません。

それは、「欲しいものを得るのに時間がかからないので、コメントなしでコードを書くのが好きだ」と言っているようなものです。

もちろん、ハードコーディングが常に非常に悪いことだと言っているわけではありません。(つまり、設定ファイルに π や e、プランク定数などの数学定数を保存するのはちょっとばかげているでしょう。また、サイン/コサイン値などのルックアップテーブルをハードコーディングすると、おそらくファイルからロードするよりもはるかに効率的です。) しかし、単に利便性のためにデータをハードコーディングすることは賢明な考えではありません。柔軟性がなく、後でデータを変更するのが必要以上に面倒になります。

また、ハードコーディングは、多くの状況で不可能ではないにしても、ローカリゼーションを非常に困難にする可能性があります。それが会社の内部アプリであれば、ある程度は問題にならないと思いますが、それは一般的に良いソフトウェア開発手法にはなりません。

score 0 · Accepted Answer

すべてのケースをカバーする主張を行うことはほとんどできないいくつかの要因が関係しています。

いくつかのサイクルがある長いプロジェクトの場合、ハードコーディングを開始すると、すぐに再びポップアップする可能性があります。したがって、これらの場合は、適切なソリューションで修正することをお勧めします。

しかし、短いサイクルのプロジェクトや事前定義されたスケジュールのプロジェクトがあり、とにかく製品を出荷する必要がある場合、ほとんどのクライアントは製品が機能すれば満足し、内部構造は気にしません. しかし、これらの場合、解決策をハードコーディングすることを好みますが、パスを開いたままにしておくと、将来的に適切な解決策を簡単に作成できるようになります。

とにかくハードコーディングは悪いですが、適切に文書化することで、次の人の人生がはるかに楽になり、おそらくあなたを呪うことはありません;) .

しかし、私の経験から、外出先からハードコードすることを避け始め、他に選択肢がない場合にのみそれらを使用し、それらのケースを常に文書化して、後で時間があるときに適切に修正できるようにしました。

score 0 · Accepted Answer

私は通常、ハードコードするのではなく、構成ファイルに値を入れようとします。値をハードコードする必要がある場合は、ハードコードされた値で定数を作成し、コード内のすべての場所で同じ定数を参照します。値を変更する必要がある場合は、1 か所で変更できます。

アプリケーション全体の定数については、通常、クラスを作成し、その中に定数を作成します。

score 0 · Accepted Answer

私は常に定数を作成しますが、その「唯一の」用途がどこにあるかにできるだけ近い/賢明です。

その後、ユニット内の別の場所で必要になった場合は、ユニットの上部に移動します。

その後、別のユニットで必要な場合、定数は設定ユニットに移動されます。

誰かがそれを変更可能にしたい場合は、設定ユニットに移動され（まだ設定されていない場合）、構成ファイルなどから設定されます。

結局のところ、あなたが付けた名前はそのドキュメントです。少なくとも、あなたの 73 を他の誰かの 73 と混同しないことを意味します。

score 0 · Accepted Answer

C/C++ のハードコードされた文字列について; 私は通常、ハードコーディングを回避する最も簡単な方法としてそれらを #define します (ある意味ではまだハードコーディングされています)。その理由は、スペルが間違っている定義済みの識別子はコンパイラによって検出されますが、引用符で囲まれたものは検出されないためです。

score 0 · Accepted Answer

構成に対する私の態度は？多くの場合、これは不十分でカジュアルに行われています。ユーザーが何百もの構成可能な値を理解しようとすると、TCO が増加します。必要性が証明された場合にのみ、構成可能性 (ソフトコーディング) を追加します。

必要な場合 ... 構成可能な値は、ユーザー入力と同じように不信感を持って扱われ、入力が不適切な場合は明確なエラーメッセージを表示する必要があります。ほとんどのコンポーネントは、データアクセスインフラストラクチャからほとんどのコンポーネントを分離するのと同じように、構成インフラストラクチャから分離する必要があります。構成インフラストラクチャから分離したら、コンポーネントが構成システムからのさまざまな「入力」をどのように処理するかをテストできます。最も重要なことは、プログラムは最小限の構成で問題なく動作することです。

ただし、このタイプのアンチパターンは非常に一般的です。

File.Open(configuration["widgetsFileStorage"] + "/" + widgetImage)

またはこれ（ユーザー入力を直接hrefに入れることはありますか？私はしません。どういうわけか、多くの人は構成値を信頼しすぎています）。

LinkWriter.href=configuration["supportUrl"]

構成するタイミングあなたが証明するように、あなたがする必要があります。関心を適切に分離すると、後で値を構成可能にすることが容易になります。ファイルロケータにファイルを配置する責任は取り下げます。

File.Open(new WidgetFileLocater().GetUncPath(widgetImage))

ファイルロケータの背後のどこかで、構成ファイルやデータベースを参照する場合と参照しない場合があります。おそらく、アプリケーションディレクトリ内の「images」ディレクトリへのハードコーディングを開始します。構成は、柔軟性のユースケース (誰かがそれを SAN に配置したい場合) がある場合に行われますが、それ以前ではありません。とにかく、ほとんどのアプリは、構成されているかどうかに関係なくすべきではありません。ファイルロケーターで依存性注入を使用して、構成ファイルからのお粗末な入力が正しく処理されていることを確認する可能性があります。

また、ほとんどの場合、構成は緩く型付けされ、コンパイルされていないため、コードよりもはるかに危険です。このリスクが開発者によって尊重されることはめったにありません (ただし、システム管理者は大いに尊重します)。構成のニーズに合わせて python / ironpython / boo のようなスクリプト言語を使用することについて議論しました。xml やテキストよりもはるかに自由な構文と型チェックを使用して、コンパイル後に内容を変更することができます。

警告: 私の態度は反復的なリリースサイクルを前提としています。Microsoft のように 2 ～ 10 年のリリースサイクルがある場合は、より多くの値を構成することを優先してバイアスをかけたいと思うでしょう。

coding-style - ハードコーディングに対するあなたの態度はどうですか？

17 に答える 17

Related

Reference