開発者がコードの意味よりもコンパイルされたバイトの結果に関心があることを指摘する質問に対する多くの反応に、私は少し驚いています。私は、2つの値を持つ列挙型にブール値を使用すること、および適切な関数の命名について、そして...
したがって、問題はより現実的な世論調査です。自分が書いたもののセマンティクスを無視できるのはいつですか。境界線はどこですか？
それに名前を付けます。
編集 -
（マイクロ）最適化の必要性について質問するつもりはありませんでした。むしろ、自分が書いていることをどれだけよく知っているべきか、そして「とにかく、それはdwordにコンパイルされるので、なぜそれを列挙型にする必要があるのか」などのステートメントについて意見が欲しいです。（これは極端なケースです...）。
「ok」を定義します。最初の納期で機能しても大丈夫ですが、変更が必要になるたびに、古いコードを理解するのにさらに3週間かかりますか？
あなたの答えがあります：あなたがコードを理解でき、それがあなたのそれを維持する能力を傷つけない限り。
私は自分のキャリアの中でたくさんのコードを書きました。確かにここの人々ほど多くはありませんが、それでも多くのコードがあります。その間、私は何度も真実であることが証明された1つのことを学びました。だらしなくなったとき、細部を無視したとき、欠陥が忍び寄ります。
欠陥は修理に時間とお金がかかります。安価なときに、コードを前もってきれいに明確に書くために時間を費やすか、後でコードの欠陥を追いかけるために多くの時間とお金を費やすことができます。急いで、またはコーディング標準に準拠していないために、一緒に叩きました。その結果、時間とお金を無駄にしていることになります。さらに、少しの先行投資で防ぐことができたので、最初から無駄にする必要がなかった時間とお金を無駄にしています。
コードの書き方に細心の注意を払ったことを後悔したことはありません。それは私を悩ませるために戻ってきたことはありません。ずさんなことはいつも私を悩ませるために戻ってきました。
収益に影響を与えない難解なものについて心配し始めると、それは行き過ぎだと思います。三項演算子を使用するか、または何もすることがない時代にステートメントが適切であるかどうかを明示的に書くかどうかなどの議論は、座って、足を上げ、ビール/ワイン/ソーダを飲み、「大きな結果」の問題について議論します:)
しかし、ブール値の列挙型を作成するのはまったく間違っています。
コスト関数によって異なります
ここでは、人々が議論するのが大好きで、しばしば混同するいくつかの側面があります。本当に、答えはそれが依存するということです。あなたが本当に大切にしていることは何ですか？
私は常に明快さのように、より高次のものを最初に目指します。明確さの喪失は、常に不足している人間のサイクルで支払われます。人々は生の時計の時間を気にすることはめったになく、そう言う人はほとんどの場合時期尚早に最適化しています。
それがあなたの助けになるなら、私たちはスタックを上って、ビットと数字の奴隷になるのではなく、セマンティクスと仕事の遂行にもっと気を配ることによって進歩していると思います。ただし、これは基本を忘れて、特定のセマンティックビットがどのように実装されているかを覚えておくための言い訳にはなりません。スピードが重要になり始め、慣習が窓の外に出るというまれな機会の間に、ズボンを下ろして捕まえられたくはありません。
「自分が書いたもののセマンティクスを無視できるのはいつですか？境界線はどこにありますか？」
合理的な質問は、「自分が書いたもののセマンティクスをいつ無視すべきか」ということだと思います。
私はプログラミングを人間の活動と見なしているので、ステートメントのセマンティクスを無視する必要があるのは、システム自体が強制するとき、つまり理解できないステートメントが何かを行う唯一の方法であるときだけだと思います。そのようなステートメントは文書化するのに適しています。
境界線は、write-once、read-neverコードを処理する場合です。そうして初めて、二度と使用することはないので、最終的には（その場合は）何をしているのかは重要ではありません。残念ながら、これは、繰り返したくないことを実践するという間接的なフィードバックには対応していません。
境界線は副作用です。
カプセル化された関数が予期しない副作用なしで必要なすべてを実行し、コードが読み取り可能である場合、それが重要です。外部ユーザーに予測可能であり、「奇妙な」機能が内部で保持されている場合は、それだけが重要です。
最適化を追加するとわずかに変化しますが、時期尚早に最適化するべきではないので、それで終わりです。
最近では、正しく機能することを前提として、読みやすさが最も重要な考慮事項であることにほとんどの人が同意していると思います。もちろん、例外もあります。一部のアプリはできるだけ高速に実行する必要があり、一部のアプリはクラッシュを許可されませんが、一般的には読みやすさです。
マイクロ最適化は 99% の確率で無意味です。たとえば、コンパイラがとにかくすべての "" を 1 つのインスタンスにインターンする場合、String.Empty を使用してもパフォーマンスは向上しません。通常、測定可能な効果がないことは、期待できる最善の方法でもあります。コンパイラーがより良い仕事をし、最適化がそれを妨害するため、「最適化」がパフォーマンスを低下させるのを見てきました。
ほとんどのコードは最適化する必要はありません。それが必要な場所を特定するには、コードの実行後に診断を行う必要があります。その場合でも、ほとんどの場合、マイクロ最適化ではなく、アルゴリズムによる最適化によって行われます。
あなたが提供した例を観察する - 以下：
operator++(接尾辞/接頭辞)
string.empty()対。string == ""
で異なる操作を比較しているため、良い例とは思えませんfunctionality。したがって、それらの意味上の区別を無視しないほうがよいでしょう。
対照的に、次の例は次のとおりです。
vector.empty()対。vector.size() == 0
enumerate { on, off} vs. boolean on=true;off=false
完全に合理的です。
vector.empty()その使用のコンテキストが、ベクトルが空かどうかを判断することだけである場合は、見下すように聞こえるかもしれませんが（そうするつもりはありません）、これは常識に帰着します。ベクトルが空かどうかだけ知りたいのに、なぜベクトルのサイズを尋ねるのでしょうか? これは、コーラを飲むのに十分な現金があるかどうかを知りたいときに、財布にいくら入っているかを尋ねるようなものです。
enumerate { on, off} vs. boolean on=true; については off=false、これを自問してください。将来、列挙に別の値を追加する可能性はどのくらいありますか? enumerate{ on, off, }` (またはいくつかのバリエーション) が必要になるのは理にかなっているように思われるindeterminateので、答えはイエスかもしれません。それ以外の場合は、単純なブール値で十分です。
これは私をあなたの質問の核心に導きます:これは、これらのような質問、またはそれらの関連性について何らかの方法で決定するための決定論的/アルゴリズム的アプローチがあるかどうかのようです? 私の答えは、チューリング マシンがチューリング テストに合格できる日まではノーと言います。これが、人間がソフトウェアを設計する必要がある理由です。