12

これは受け入れられるコーディング方法ですか?

public class MessageFormat {
    private static final Color DEFAULT_COLOR = Color.RED;

    private Color messageColor = DEFAULT_COLOR;

    public MessageFormat(Person person) {
        Color color = person.getPreferredColor();
        messageColor = (color != null) ? color : messageColor; // this line
    }
}

それともクラシックの方がいいのでしょうか...

if (color != null) {
    messageColor = color;
}
4

8 に答える 8

25

?: 演算子の使用は、コードを読みやすくするために制限する必要があります。典型的な例:

a = sprintf( "There are %i green bottle%s on the wall.", i, (i==1?"":"s") );

この場合、コードを約 5 行の if/else に分割すると、コードが読みにくくなります。

私は通常、演算子全体を括弧で囲んで、それを読むときに精神的に単一の値として解析できるようにします。

 messageColor = (color != null ? color : messageColor);

別のバリアントは

messageColor = color || messageColor;

色が "false" と評価されない限り、一部の言語では "色" と評価されます。その場合、messageColor の値です。私の意見では、これは人々を混乱させる可能性があるため、避けるべきです。

最も重要なことは、コードを次に読む人 (たとえそれがあなたであっても) の認知オーバーヘッドが最小限になるように、一貫性を保つことです。

于 2009-11-29T10:45:08.587 に答える
4

この場合、読みやすさ、わかりやすさなどは同じです (というか... )。最初の例の重複と明らかな自己割り当ては好きではありません。次のように変換されます。

if (colour != null) {messageColour = colour;}
   else {messageColour = messageColour;};

これは少しばかげています。

通常は 2 番目を 1 行で記述しますが、それは個人の好みの問題です。コーディング スタイルのガイドライン:

if (colour != null) {messageColour = colour;};

編集（私は今、8年前よりも独断的です）

ベストプラクティスを探しているので：

// Use default visibility by default, especially in examples.
// Public needs a reason.
class MessageFormat {
    static final Color DEFAULT_COLOR = Color.RED;

    // Strongly prefer final fields.
    private final Color messageColor;

    // Protect parameters and variables against abuse by other Java developers
    MessageFormat (final Person person) {
        // Use Optionals; null is a code smell
        final Optional<Color> preferredColor = person.getPreferredColor();
        // Bask in the clarity of the message
        this.messageColor = preferredColor.orElse(DEFAULT_COLOR);
    }
}
于 2009-11-29T11:39:55.177 に答える
2

三項演算子の使用は、多くの場合、他のコーディング標準と同様にデリケートな問題です。その使用は、おそらくサイトのコーディング標準によって最もよく決定されます。

ただし、この特定の状況では、2 番目のオプションをお勧めします。より明確なだけでなく、ここでは三項演算子の使用はまったく不要です。messageColor をそれ自体に再割り当てする必要はないため、この特定の状況での三項演算子の唯一の機能はコードの難読化です。

于 2009-11-29T10:37:08.503 に答える
2

三項演算子は、C プログラマの間でより一般的です。C では、制御構造を回避すると、分岐予測がうまくいかないため、パイプライン処理が改善されることがよくあります。Java でパフォーマンスの違いが見られるとは思えません。if-null-then-assign パターンは 3 項よりもはるかに一般的です。ただし、既存のコードベースを維持している場合は、通常、既存のコードとの一貫性を保つことが最善です。

これを頻繁に行う場合は、defaultIfNull、firstNonNullまたはcoalesce関数を記述して、コードをさらに簡潔にすることができます。 Apache Commons Lang にはdefaultIfNull関数が含まれています。

一部の言語には||=演算子が含まれています。これは、これらの言語でデフォルト値を設定するための通常のイディオムです。

于 2009-11-29T10:42:01.950 に答える
1

意味をより明確に表現しているため、私は2番目を好みます.nullでない場合にのみ色を変更したい. 最初の方法では、これが明確になりません。

于 2009-11-29T10:33:47.443 に答える
1

三項演算子は、生成されるコードが巧妙でコンパクトに見えるため、悪用されることがよくあります。

実際、コードが読みにくくなり、エラーが発生しやすくなります。可能な限り、より長いバージョンの

 if ( <condition> ) {
     <action> ;
 }

三項構文の代わりに。

于 2009-11-29T10:38:20.320 に答える
1

あなたの場合、私は「古典的な」実装を好みます。なぜなら、人が好みの色を持っている場合にのみ新しい色を使用したいということを理解するのが速いからです。

NPE を回避したい場合は、メソッド呼び出しで使用することもありますが、通常は次のリファクタリングの 1 つでこれらの醜いコードを削除します ;)

于 2009-11-29T11:25:41.237 に答える
0

私には問題ないように思えますが (私は Python の三項演算子をよく使用します)、この種のスタイルの問題は通常、非常に主観的なものです。プロジェクトにコーディング スタイル ドキュメントがある場合は、それを確認することをお勧めします。

于 2009-11-29T10:33:24.370 に答える