Phá vỡ trường hợp mặc định trong chuyển đổi

Tôi hơi bối rối về bất cứ khi nào hoặc không bao gồm breaksau trường hợp cuối cùng, thường xuyên default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breakMục đích duy nhất của tôi là theo cách hiểu của tôi để ngăn chặn mã chạy qua phần còn lại của switchvali.

Sau đó, nó được coi là hợp lý hơn để có một breakcuối cùng do tính nhất quán hoặc bỏ qua có nó do breakáp dụng không sử dụng chức năng gì? Cả hai đều hợp lý theo những cách khác nhau theo ý kiến ​​của tôi.

Điều này có thể ở một mức độ nhất định được so sánh với việc kết thúc một .phptập tin với ?>. Tôi không bao giờ kết thúc với ?>phần lớn là do rủi ro xuất ra các khoảng trống, nhưng người ta có thể lập luận rằng đó sẽ là điều hợp lý để kết thúc tệp.

breakkhông cần thiết về mặt kỹ thuật sau giải pháp thay thế cuối cùng (mà theo bạn, không cần phải như vậy default: nó hoàn toàn hợp pháp và đôi khi còn hữu ích để đặt defaultchi nhánh lên hàng đầu); liệu mã của bạn rơi vào cuối switchcâu lệnh hay breaksở cuối nhánh cuối cùng của nó có cùng kết quả hay không.

Tuy nhiên, tôi vẫn kết thúc mọi chi nhánh, kể cả chi nhánh cuối cùng, bằng một tuyên bố returnhoặc break, vì ba lý do:

1. Tái cấu trúc. Nếu tất cả các chi nhánh của bạn kết thúc bằng breakhoặc return, bạn có thể sắp xếp lại chúng mà không thay đổi ý nghĩa. Điều này làm cho nó ít có khả năng sắp xếp lại như vậy để đưa ra hồi quy.
2. Kiên định, và ít ngạc nhiên nhất. Tính nhất quán nói rằng các chi nhánh của bạn nên kết thúc một cách nhất quán, trừ khi chúng thực sự khác nhau về ý nghĩa. Nguyên lý bất ngờ tối thiểu cho rằng những thứ tương tự sẽ trông giống nhau. Kết thúc nhánh cuối cùng của một switchkhối chính xác như các khối trước đáp ứng cả hai, điều này giúp cho việc đọc và hiểu dễ dàng hơn. Nếu bạn bỏ qua phần rõ ràng break, nhánh cuối cùng sẽ khác về mặt quang học (điều đặc biệt quan trọng đối với việc quét nhanh) và để thấy rằng nó thực sự không khác biệt, người đọc phải hạ xuống mức độ khó đọc của từng câu lệnh .
3. Bảo vệ chính mình. Nếu bạn tạo thói quen kết thúc tất cả các switchchi nhánh của mình bằng một break, nó sẽ tự động trở lại sau một thời gian và bạn sẽ ít có khả năng vô tình quên nó ở nơi có vấn đề. Rèn luyện bản thân để mong đợi breakở cuối mỗi chi nhánh cũng giúp phát hiện các breakcâu lệnh bị thiếu , rất tốt cho việc gỡ lỗi và khắc phục sự cố.

Do sự mơ hồ tồn tại xung quanh việc sử dụng switch-casetrong hầu hết các ngôn ngữ, khi sử dụng nó, tôi sẽ đề nghị luôn luôn sử dụng một breakcâu lệnh, ngoại trừ khi nó không rõ ràng và theo thiết kế không muốn .

Một phần điều này là do làm cho mọi casecuộc gọi trông giống nhau, mà theo tôi sẽ cải thiện khả năng đọc. Nhưng điều đó cũng có nghĩa là nếu ai đó (thậm chí là bạn) chọn chèn casesau cái cuối cùng ở giai đoạn sau, họ không cần quan tâm đến việc kiểm tra khối trước, điều này có thể giúp giảm lỗi khi thêm mã mới.

Không breakcần thiết sau trường hợp cuối cùng . Tôi sử dụng từ " cuối cùng " (không phải mặc định ) vì trường hợp mặc định không cần thiết là trường hợp cuối cùng.

switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}

Và chúng ta biết, a break là cần thiết giữa hai cases liên tiếp . Đôi khi, tôi sử dụng if(a!=0)mã của mình để dễ đọc hơn khi người khác giới thiệu mã của tôi. Tôi có thể chọn sử dụng if(a), đó sẽ là vấn đề lựa chọn của tôi