Tiêu chuẩn bình luận $ FALL-THROUGH $ của Eclipse?

Question

Tôi sử dụng Eclipse, vì vậy với tôi, việc sử dụng các chú thích //$FALL-THROUGH$ của chúng tôi là thực tiễn phổ biến trên các câu lệnh chuyển đổi và tương tự. Nhưng đồng nghiệp của tôi sử dụng Netbeans và hỏi tôi đang làm gì với những thứ này. Và cố gắng để google bất cứ điều gì với một biểu tượng trong nó giống như cố gắng để kéo răng với một cặp găng tay đông lạnh và không có công cụ ...

Việc sử dụng các bình luận //$FALL-THROUGH$, ký hiệu đô la và tất cả, một tiêu chuẩn java điều, hoặc một số loại phép thuật Eclipse? Nếu tôi tải lên cùng một mã trong Netbeans hoặc IDE khác, hoặc chạy nó thông qua trình biên dịch java độc lập, sẽ rơi thông qua các câu lệnh chuyển đổi vẫn được đánh dấu bằng cảnh báo, ngay cả với bình luận đã nói hay không? Có cách nào một cách tiêu chuẩn để thực hiện việc này ngoài việc sử dụng chú thích @SupressWarning (chỉ đơn giản là mã lộn xộn cho biết bạn phải sử dụng nó như thế nào)?

Answer 1

Những thứ như thế này phụ thuộc vào công cụ IDE/phong cách-công cụ phụ thuộc. Không có "bình luận Java chuẩn".

^{(Vâng, Javadocs là tiêu chuẩn, nhưng chúng tôi không kiểm soát biên soạn/báo cáo lỗi.)}

Giải thích về $FALL-THROUGH$ xây dựng được đề cập trong nhật thực release documentation:

Vấn đề biên dịch cho dự kiến ​​mùa thu trong báo cáo trường hợp chuyển đổi bây giờ có thể được ngăn chặn bởi trước tuyên bố trường hợp sau đây với một bình luận bắt đầu với $ FALL-THROUGH $. Điều này đặc biệt thú vị đối với mã không thể sử dụng chú thích @SuppressWarnings ("fallthrough") kiểu J2SE-5.0.

Lưu ý rằng tên cảnh báo cho chú thích @Suppresswarnings phụ thuộc vào trình biên dịch chứ không phải là tiêu chuẩn ngôn ngữ Java.

Answer 2

Tôi đã thấy các công cụ khác (ví dụ: FindBugs) sử dụng lược đồ nhận xét tương tự. Nhưng không có gì được tiêu chuẩn hóa.

Trong hầu hết các trường hợp, các cảnh báo này chỉ được ném khi tuyên bố trường hợp chứa mã trước khi hết hạn. Trong hầu hết các trường hợp, bạn có thể tránh điều này bằng cách tính ra mã chung.

Ví dụ này sẽ không bình thường gây ra một cảnh báo:

switch (foo) { 
    case 1: 
    case 2: 
    doSomething(); 
    break; 
    ... 
} 

Nhưng điều này sẽ:

switch (foo) { 
    case 1: 
    doSomething(); 
    case 2: 
    doSomethingElse(); 
    break; 
    ... 
} 

Cá nhân tôi nghĩ rằng những lời cảnh báo là có một lý do. Tôi coi nó dễ đọc hơn (và an toàn) để cấu trúc lại ra mã phổ biến và không có không có sản phẩm nào vào mùa thu-qua:

switch (foo) { 
    case 1: 
    doSomething(); 
    doSomethingElse(); 
    break; 

    case 2: 
    doSomethingElse(); 
    break; 
    ... 
} 

Answer 3

Nhận xét này là IDE cụ thể và có thể thất bại với ide và mã cờ khác, mặc dù FindBugs là thông minh đủ để kiểm tra ý kiến ​​với từ rơi vào chúng. Nhưng, trong mọi trường hợp bạn không nên dựa vào ý kiến ​​để làm nhiều hơn là chỉ đạo lập trình viên, bạn chỉ đang tạo ra một thứ nữa để duy trì.