Có cần thiết phải thêm trường hợp mặc định trong khi sử dụng trường hợp chuyển đổi?

Trong một lần xem xét mã gần đây, tôi đã được yêu cầu đặt defaultcác trường hợp vào tất cả các tệp ở bất kỳ nơi nào switchđược sử dụng, ngay cả khi không có gì để làm default. Điều đó có nghĩa là tôi phải đặt defaulttrường hợp và không viết gì trong đó.

Đây có phải là điều đúng để làm gì? Mục đích gì nó sẽ phục vụ?

Có vẻ như có ba trường hợp khi một defaulttuyên bố là không cần thiết:

1. không có trường hợp nào còn lại, vì có một bộ giá trị giới hạn nhập vào switch case. Nhưng điều này có thể thay đổi theo thời gian (cố ý hoặc vô tình) và sẽ tốt hơn default casenếu có bất cứ điều gì thay đổi _ bạn có thể đăng nhập hoặc cảnh báo người dùng về một giá trị sai.

2. bạn biết làm thế nào và ở đâu switch casesẽ được sử dụng và những giá trị nào sẽ nhập vào nó. Một lần nữa, điều này có thể thay đổi và có thể cần xử lý thêm.

3. các trường hợp khác không cần bất kỳ xử lý đặc biệt. Nếu đây là trường hợp, tôi nghĩ bạn được yêu cầu thêm một default case, bởi vì đó là một kiểu mã hóa được chấp nhận và nó làm cho mã của bạn dễ đọc hơn.

Hai trường hợp đầu tiên dựa trên các giả định. Vì vậy (giả sử bạn làm việc trong nhóm không quá nhỏ vì bạn có đánh giá mã thường xuyên), bạn không thể đủ khả năng đưa ra các giả định đó. Bạn không biết ai sẽ làm việc với mã của bạn hoặc thực hiện cuộc gọi đến các hàm / gọi các phương thức trong mã của bạn. Tương tự, bạn có thể cần phải làm việc với mã của người khác. Có cùng kiểu mã hóa sẽ giúp bạn dễ dàng xử lý mã của ai đó (bao gồm cả mã của bạn).

Đây có phải là thiong phải làm? Mục đích gì nó sẽ phục vụ?

Không có gì lạ khi các tiêu chuẩn mã hóa của công ty yêu cầu một trường hợp mặc định cho tất cả các switchcâu lệnh. Một lý do cho nó là nó giúp người đọc dễ dàng tìm thấy sự kết thúc của switch. Một lý do khác, có lẽ tốt hơn là nó khiến bạn suy nghĩ một chút về việc mã của bạn nên làm gì khi điều kiện không phù hợp với mong đợi của bạn. Bất kể lý do cho yêu cầu là gì, nếu đó là tiêu chuẩn của công ty, bạn nên tuân theo yêu cầu đó trừ khi không có lý do kín đáo.

Nếu bạn tin rằng switchbao gồm các trường hợp của bạn cho mọi điều kiện có thể, thì một điều tốt để làm là đặt một asserttuyên bố trong trường hợp mặc định. Theo cách đó, khi ai đó thay đổi mã và vô tình thêm một điều kiện mà bạn switchkhông bao gồm, họ sẽ nhấn assertvà nhận ra rằng họ cần giải quyết phần đó của mã.

Nếu bạn switchchỉ bao gồm một vài điều kiện có thể, nhưng không có gì đặc biệt phải làm cho những điều kiện khác, bạn có thể để trống trường hợp mặc định. Đó là một ý tưởng tốt để thêm một nhận xét trong trường hợp đó để chỉ ra rằng trường hợp mặc định là cố ý để trống vì các điều kiện xảy ra không cần phải thực hiện bất kỳ công việc nào.

Nếu bạn "chuyển đổi" sang loại liệt kê thuần túy, sẽ rất nguy hiểm nếu có dự phòng mặc định. Khi bạn thêm các giá trị vào loại liệt kê, trình biên dịch sẽ làm nổi bật các công tắc với các giá trị mới không được bảo hiểm. Nếu bạn có mệnh đề mặc định ở đó, trình biên dịch sẽ giữ im lặng và bạn có thể bỏ lỡ nó.

Trong nhiều khía cạnh, câu hỏi này giống như câu hỏi Tôi thường cần một elsemệnh đề ở cuối if/ else ifthang bao gồm mọi tùy chọn .

Câu trả lời là, về mặt cú pháp, không có bạn. Nhưng có một ... tuy nhiên ...

Một defaultmệnh đề có thể ở đó vì (ít nhất) hai lý do:

1. Là một người xử lý lỗi - chắc chắn, không bao giờ nên đến đây! là một yêu cầu có thể được thực hiện, nhưng nếu nó xảy ra thì sao? Tham nhũng dữ liệu, hoặc thậm chí tệ hơn, không có xác thực dữ liệu là các tuyến dẫn đến lỗi chương trình nếu không được đặt đúng cách. Trong trường hợp này, nó không nên là một mệnh đề trống!
2. Thiết kế / Bảo hiểm mã - ngay cả ở dạng đơn giản nhất của biểu đồ dòng chảy, có hai tuyến từ một câu lệnh if và luôn luôn là otherwisetừ một trường hợp. Không có lý do gì để không bao gồm những thứ này trong mã nguồn.

Triết lý của tôi luôn khá đơn giản - đánh giá trường hợp xấu nhất trong hai lựa chọn và đi cho an toàn nhất. Trong trường hợp trống elsehoặc defaultmệnh đề, các tùy chọn trường hợp xấu nhất là:

• Bao gồm chúng: Thêm ba hoặc bốn dòng mã "dự phòng".
• Không bao gồm chúng: Dữ liệu giả hoặc một điều kiện bất ngờ không bị mắc kẹt, có khả năng gây ra lỗi chương trình.

Quá sức? Có lẽ ... nhưng sau đó phần mềm của tôi có khả năng giết người nếu nó sai. Tôi thà không chấp nhận rủi ro đó.

Bên cạnh đó, các hướng dẫn của MISRA-C {xem hồ sơ để liên kết} đề xuất một defaultđiều khoản cho mọiswitch

Java không bắt buộc bạn phải có một câu lệnh 'mặc định' nhưng đó là một cách tốt để có tất cả thời gian, ngay cả khi mã có thể không bao giờ đạt được (ngay bây giờ). Đây là một vài lý do:

Bằng cách có một mệnh đề mặc định không thể truy cập, bạn hiển thị cho người đọc mã của bạn rằng bạn đã xem xét các giá trị và biết bạn đang làm gì. Bạn cũng cho phép thay đổi trong tương lai, ví dụ: một giá trị enum mới được thêm vào, công tắc không nên âm thầm bỏ qua giá trị mới; thay vào đó bạn có thể ném Ngoại lệ hoặc làm việc khác.

Để bắt một giá trị không mong muốn (trong trường hợp bạn không bật enum) được truyền vào - chẳng hạn, nó có thể lớn hơn hoặc ít hơn so với những gì bạn mong đợi, chẳng hạn.

Để xử lý các hành động 'mặc định' - trong đó các công tắc dành cho hành vi đặc biệt. Ví dụ, một biến có thể được khai báo bên ngoài công tắc nhưng không được khởi tạo và mỗi trường hợp khởi tạo nó thành một cái gì đó khác nhau. Mặc định trong trường hợp này có thể khởi tạo nó thành một giá trị mặc định để mã ngay sau khi chuyển đổi không bị lỗi / ném ngoại lệ.

Ngay cả khi bạn quyết định không đặt gì vào mặc định (không có ngoại lệ, ghi nhật ký, v.v.) thì ngay cả một nhận xét để nói rằng bạn đã xem mặc định thực tế sẽ không bao giờ xảy ra có thể giúp đọc mã của bạn; nhưng điều đó đi xuống sở thích cá nhân.

Tôi cũng sẽ nói thêm rằng nó phụ thuộc vào triết lý của ngôn ngữ bạn đang sử dụng. Ví dụ, trong Erlang, đó là cách tiếp cận phổ biến để 'để nó bị sập', bạn sẽ không xác định trường hợp mặc định mà hãy để casecâu lệnh của bạn gây ra lỗi nếu một tình huống xảy ra không được phục vụ.

Bạn phải luôn luôn có một mặc định trừ khi bạn có thể bao quát tất cả các trường hợp. Không có chi phí gì, và đó là bảo hiểm chống lại việc không duy trì tuyên bố chuyển đổi của bạn trong một chương trình phát triển.

Nếu bạn thực sự chắc chắn rằng bạn không quan tâm đến bất kỳ trường hợp nào khác, thì mặc định: break; // không quan tâm nhưng mặc định mặc định sẽ là một cái gì đó như mặc định: ném Lỗi mới ("giá trị không mong muốn");

Tương tự như vậy, bạn không bao giờ nên "bỏ qua" một cấu trúc trường hợp không cần thiết mà không thêm nhận xét vào hiệu ứng mà bạn dự định bỏ qua. Java đã sai điều này ở giai đoạn thiết kế.

Xem xét

enum Gender
{
       MALE ,
       FEMALE ;
}

và

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Tôi sẽ lập luận rằng điều này là vượt trội so với trường hợp MALE, trường hợp FEMALE và trường hợp mặc định đưa ra một ngoại lệ.

Trong giai đoạn thử nghiệm của bạn, máy tính sẽ kiểm tra xem g có phải là FEMALE không. Trong quá trình sản xuất, kiểm tra sẽ được bỏ qua. (Vâng, một vi mô hóa!)

Quan trọng hơn, bạn sẽ duy trì mục tiêu bảo hiểm mã 100%. Nếu bạn đã viết một trường hợp mặc định ném Ngoại lệ, bạn sẽ kiểm tra nó như thế nào?