デフォルト値-それらは良いですか、悪いですか？

一般的なデフォルト値に関する質問-デフォルトの戻り関数値、デフォルトのパラメーター値、欠落している場合のデフォルトのロジック、例外を処理するためのデフォルトのロジック、エッジ条件を処理するためのデフォルトのロジックなど

長い間、私はデフォルト値を「純粋な悪」なものだと考えていました。これは「大惨事を覆い隠し」、バグを見つけるのが非常に難しいものです。しかし最近、デフォルト値をある種の技術的負債として考えるようになりました...これはまっすぐに悪いことではありませんが、「短期資金」を提供してプロジェクトを生き残ることができます住宅ローンを出さずに家を買う？）。

私が「短期」と言うとき-私は意味しません-「最初に何かを迅速に行い、後でプロダクションにヒットする前にそれをリファクタリングします」。いいえ-実稼働ソフトウェアのハードコードされたデフォルト値に依存することについて話している。確かに-それはいくつかの問題を引き起こす可能性がありますが、それが一年で単一のトラブルを引き起こすだけならどうでしょう。

繰り返しますが、ここでは「平均的な」メインストリームソフトウェア（原子力発電所のソフトウェアではありません）について話しています。平均的なWebサイトまたは会計ソフトウェアのUIアプリケーションです。 。

繰り返しになりますが、私の経験から、ビジネスユーザーは完璧なソフトウェアを待つのではなく、「何らかの形で機能する」ソフトウェアを使いたいと考えています。また、RADスタイルのソフトウェアを開発する場合、デフォルト値の使用は非常に役立ちます。しかし、再び-私が費やした最長のデバッグセッションは、途中で「デフォルト」でなくなったデフォルト値によって導入されたバグ、または小さなサブシステムが最近アップグレードされたため、このアップグレードの結果ではありませんデフォルトを正しく処理します（たとえば、空のリストとnull、またはnullの文字列と空の文字列）。

だから私の質問は-デフォルト値は良いか悪いかです。そして、それらが技術的負債である場合-返済を支払う余裕があるように、どのくらい借りることができるかをどのように測定しますか？

どんな入力でも本当に感謝します。

乾杯。

編集：

開発中にコーナーをカットする方法としてデフォルト値を使用している場合-コーナーのカットによりバグや問題が発生する場合-これらの問題から回復する方法は何ですか？

合理的なデフォルト値がなければ、設定に対する規約の概念は不可能です。ここでのキーワードは「賢明」です。デフォルト値は、ライブラリ/サービス/フレームワークのすべての使用の少なくとも80％（それ以上ではない場合）で意味がなければなりません。

一般的な経験則：

• 値が80％以上の使用に適している場合、デフォルト値である必要があります
• ほとんどの場合に使用される値がない場合は、デフォルトを使用しないでください。
• デフォルト値は、セットアップコードからの愚かな間違いを防ぎます。ほとんどの場合、デフォルトが妥当であれば、作業構成を台無しにする人は少なくなります。
• デフォルトを使用すると、非標準構成がより見やすくなります。
• 悪いデフォルトは、デフォルトがないよりも悪いです。

基本的に、デフォルトの構成がどのように機能するかを学習したら、非標準の構成をいつどのように行うかについて、知識に基づいた決定を下すことができます。

FTPプロトコルを実装するライブラリを例に取ります。デフォルトでは、FTPはポート21で動作することが期待されています。ランダムFTPクラスのオブジェクトを作成するたびにポート21を使用するように指定する必要がある場合、非常にイライラします。別のポートが必要な場合は、指定してください。

デフォルトは、健全なデフォルトである場合は完全に問題ありません。

デフォルトのキーマッピング、デフォルトのマウスボタンマッピング、デフォルトのブラウザ、システムのデフォルト言語の入力、ブートローダーのデフォルトのOSからの起動、デフォルトの配置メニュー、デフォルトのカラースキーム、デフォルトのフォントを備えたデフォルトのキーボードレイアウトを使用している可能性があります幅/高さ/顔/スタイル、デフォルトの文字セット、デフォルトのモニター解像度、デフォルト...

しかし、真剣に、あなたが抱えている懸念はデフォルトではなく、何か他のものにあると思います。デフォルトの動作は、本質的にバグを隠しません。たいていの場合、デフォルトを設定するかどうかに関係なく、コードは一般的な条件下で実行されます。未処理のエッジケースは、デフォルトが変更された場合や珍しいシナリオが発生した場合に、（おそらく適切かつ適切なテストを通じて）関係なく回避する必要があることです。

また、「キャッチオール」例外処理は、「デフォルト」と呼べるものではなく、ほぼ間違いなく設計上の欠陥です。

ユーザーまたは開発者が繰り返しタスクを実行するのを防ぐために、デフォルトを使用する必要があります。エラーや例外をマスクするために使用しないでください。エラーを防ぐためにそれらを使用することは悪い習慣ではありませんが、防止が悪い出来事を隠さない限りのみです。デフォルト値は、他のすべてと同様のツールです。適切に使用すれば、頭痛と時間を大幅に節約できます。不適切に使用すると、家全体を倒す可能性があります。

あなたが引用する問題の根本的な原因はそれ自体デフォルト値ではなく、インターフェース契約の変更、解釈の誤解および/または無効な仮定による統合の問題です。基本的に、これらすべて（特定の例）は、クライアントと開発者間、または異なる開発者/チーム間の不適切なコミュニケーションの結果であるようです。結構なことですが、これらの問題は無効なデフォルト値として現れる場合がありますが、他の無数の形式でも現れる場合があります。

症状ではなく根本原因を処理します。

また、他の優れた例で指摘されているように、デフォルト値を賢明に使用すると、ユーザーの生活が大幅に楽になる可能性があることに注意してください。それが最終的に私たちの目標ですよね？

通信プロトコル/規約の一部ではないデフォルト値は悪です。「一部ではない」ということは、プロトコルが厳密な場所では文書化されていないか、プロトコルが緩い場合は単に予期されていないことを意味します。

デフォルト値が文書化されている/期待されている場合、それは依然として悪である可能性がありますが、命を守ることもできます。ドメイン領域に依存します。非常に多くの場合、非常に危険な場合があります（たとえば、デフォルトの薬の投与量、デフォルトのエレベーター階、デフォルトの車の移動方向）。