Sử dụng toán tử bậc ba với 4 biểu thức

Question

Đây có phải là thực tiễn mã hóa có thể chấp nhận được không?

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 
    } 
} 

hay tôi khấm khá hơn đi với cổ điển ...

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

Answer 1

Việc sử dụng toán tử?: Phải được giới hạn để làm cho mã dễ đọc hơn. Ví dụ cổ điển:

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

Trong trường hợp này, mã sẽ ít có thể đọc được nếu bạn chia nhỏ thành 5 dòng nếu/khác.

Tôi thường đặt các dấu ngoặc quanh toàn bộ toán tử để khi đọc nó, tôi phân tích cú pháp nó như một giá trị duy nhất.

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

biến thể khác là

messageColor = color || messageColor; 

Mà trong một số ngôn ngữ sẽ đánh giá để "màu, trừ màu đánh giá là 'false', trong trường hợp giá trị của messageColor. Theo tôi đây nên tránh như nó có thể nhầm lẫn giữa người.

điều quan trọng nhất là phải phù hợp để người tiếp theo đọc mã của bạn (ngay cả khi đó là bạn) có overhead nhận thức tối thiểu.

Answer 2

vẻ tốt với tôi (tôi sử dụng nhà điều hành ternary Python của rất nhiều), nhưng loại này của vấn đề phong cách thường rất chủ quan . Nếu dự án có tài liệu kiểu mã hóa, bạn có thể muốn kiểm tra điều đó.

Answer 3

Tôi thích thứ hai vì nó thể hiện rõ ràng ý của bạn: bạn chỉ muốn thay đổi màu nếu nó không phải là rỗng. Phương pháp đầu tiên không làm cho điều này rõ ràng.

Answer 4

Việc sử dụng toán tử bậc ba thường là vấn đề nhạy cảm, cùng với các tiêu chuẩn mã hóa khác. Việc sử dụng nó có thể được xác định tốt nhất bằng các tiêu chuẩn mã hóa tại trang web của bạn.

Tuy nhiên, trong trường hợp cụ thể này, tôi chắc chắn sẽ đề xuất tùy chọn thứ hai; không chỉ là nó rõ ràng hơn, nhưng việc sử dụng các nhà điều hành ternary là hoàn toàn không cần thiết ở đây. Không cần phải gán lại MessageColor cho chính nó, vì vậy hàm duy nhất của toán tử ternary trong tình huống cụ thể này là mã obfuscation.

Answer 5

Nhà khai thác mạng thường bị lạm dụng vì mã họ sản xuất có vẻ thông minh và nhỏ gọn.

Thực tế, chúng làm cho mã dễ đọc hơn và dễ bị lỗi hơn. Bất cứ khi nào có thể, bạn nên sử dụng phiên bản dài hơn của

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

Thay vì cú pháp bậc ba.

Answer 6

Toán tử bậc ba phổ biến hơn trong số các lập trình viên C. Trong C nếu bạn tránh các cấu trúc điều khiển, bạn thường có thể nhận được pipelining tốt hơn, vì không có dự đoán nhánh nào bị sai. Tôi nghi ngờ bạn sẽ thấy bất kỳ sự khác biệt về hiệu suất trong Java, và mô hình if-null-then-assign là phổ biến hơn nhiều so với ternary. Tuy nhiên, nếu bạn đang duy trì một codebase hiện tại, tốt nhất là nên duy trì tính nhất quán với mã hiện có.

Nếu bạn thấy mình làm việc này rất nhiều, bạn có thể viết hàm defaultIfNull, firstNonNull hoặc coalesce có thể làm cho mã ngắn gọn hơn. Apache Commons Lang includes a defaultIfNull function.

Một số ngôn ngữ bao gồm toán tử ||=, là thành ngữ thông thường để đặt giá trị mặc định bằng các ngôn ngữ đó.

Answer 7

Trong trường hợp của bạn, tôi thích việc thực hiện 'cổ điển', bởi vì với tôi nó nhanh hơn để hiểu, rằng bạn chỉ muốn sử dụng một màu mới nếu người đó có một cái được ưa thích hơn.

đôi khi tôi sử dụng nó trong phương thức gọi nếu tôi muốn tránh NPEs, nhưng tôi thường elimate những mảnh xấu xí của mã trong một trong những phép tái cấu trúc tiếp theo;)

Answer 8

Độ khó, dễ hiểu, vv đều giống nhau ở trường hợp này (Ý tôi là, hãy truy cập ...). Tôi không thích sự sao chép và phân công rõ ràng trong ví dụ đầu tiên; nó sẽ dịch sang một cái gì đó như:

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

hơi ngu ngốc.

Tôi thường viết bài thứ hai trong một dòng, nhưng đó là câu hỏi về sự tôn trọng cá nhân ưa thích. hướng dẫn phong cách mã hóa:

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

EDIT (Tôi bây giờ hơn khăng khăng hơn 8 năm trước)

Vì bạn đang tìm kiếm thông lệ tốt nhất:

// 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); 
    } 
}