コメント置換として追加のローカル変数を導入


12

技術的に不要な追加のローカル変数を使用して、何が起こっているのかを説明するのは良いスタイルですか?

例えば:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

技術的なオーバーヘッドに関しては、コンパイラがこの追加の行を最適化することを期待しています。しかし、それは不必要なコードの肥大化と見なされますか?私の目には、古いコメントのリスクを減らします。


10
「何が起きているのかを説明するために、技術的に余分な追加のローカル変数を使用するのは良いスタイルですか?」はい。ここでは他にあまり語ることはできません。
デビッドアルノ

3
後でコードを読むときに、このようなスタイル(つまり、説明的な名前を持つ多くの中間変数を使用する)が非常に役立つことがわかります。もちろん、中間変数を導入しないことで、複雑な式を記述し、いくつかの名前を保存することができますが、なぜそうしたいのでしょうか?コードを読むのは比較的うまく書かれていてもかなりの挑戦になる可能性があるので、不必要にコードを複雑にすることは賢明な道ではないと思います。
マエル

これは、Martin FowlerのリファクタリングカタログではConsolidate Conditional Expressionと呼ばれています。
ブランディン

回答:


16

追加の変数を使用するコストはいくらですか?ほとんどの言語では、コンパイルされた言語と解釈された言語の両方でなし。

これの利点は何ですか?

  • 暗号化されたブール式を別のメソッドに抽出するのと同様に、コードが重複するリスク減少しますが、別のメソッドの場合よりもわずかに少なくなります。条件式がメソッド自体の内部で再利用される場合、変数を再利用できます。式が別のメソッドで表示される場合、表示されません。

    プログラミング言語で不変のローカル変数を使用できる場合、またはスタイルごとに、どの変数も再割り当てされないように強制する方法がない限り、このようなリファクタリングは長期的にリスクを伴う可能性があることに注意してください。変数の値が変更された場合、コードについて推論するのは非常に困難になる可能性があります。

  • あなたはされているドキュメントはコードと同期して得ることのリスクを低減します。開発者は、コメントよりも簡単に変数とメソッドの名前を更新する傾向があります。¹したがって、次のようなコードが表示されることは珍しくありません。

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

式はおそらくで始まりif (message.author == currentUser)、その後、ロックされたメッセージと、作成者である必要がなく、ロックされたものを気にしない管理者のケースを処理するように進化しました。ただし、コメントにはこれらの変更は反映されていません。

両方の利点は特に重要ではありませんが、追加の変数の低コストを考えると、実際にそれらを使用することを検討できます。

ブール式が過度に複雑になる場合は注意してください:²

  • 別のメソッドにそれを抽出し、そして:
  • 複数の単純なブール式にリファクタリングします。

上記の例は次のようになります。

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

¹出典:ビジネスソフトウェアを開発している同業者の私自身の観察。YMMV。実際の研究では、異なる結果が示される場合があります。個人的には、開発者がコードを読むとき、彼らはコードに焦点を合わせており、コメントはコードではなくドキュメントであると思います。したがって、彼らは通常コメントを読まないので、更新を期待するのは難しいでしょう。

²過度に複雑なしきい値は、単純な式で定義されます。コードをレビューする開発者の半数があなたを殺害する意図を表明すると、しきい値に達します。上記のブール式は、リファクタリングを必要とするほど単純です。ただし、4つの部分が連続しているif ((a && b) || (c && d))と、リファクタリングが可能になる可能性があります。式がフラットな場合、パーツの数はほとんど関係ないことに注意してください:if (a || b || c || d || ... || z)十分に読みやすいです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.