Chuyển đổi bản sao kê… có nên cho phép không? [đóng cửa]

Miễn là tôi có thể nhớ, tôi đã tránh sử dụng thông báo chuyển đổi. Trên thực tế, tôi không thể nhớ nó đã bao giờ đi vào ý thức của tôi như một cách khả thi để làm mọi việc vì nó đã được tôi ghi nhớ từ rất sớm rằng nó chỉ là một lỗi trong câu lệnh chuyển đổi. Tuy nhiên, hôm nay tôi xem qua một số mã sử dụng nó theo thiết kế, khiến tôi ngay lập tức tự hỏi mọi người trong cộng đồng nghĩ gì về câu lệnh chuyển đổi.

Đó có phải là thứ mà một ngôn ngữ lập trình không nên cho phép một cách rõ ràng (như C #, mặc dù nó cung cấp một giải pháp thay thế) hay nó là một tính năng của bất kỳ ngôn ngữ nào đủ mạnh để nằm trong tay của lập trình viên?

Chỉnh sửa: Tôi không đủ cụ thể với những gì tôi muốn nói về việc vượt qua. Tôi sử dụng loại này rất nhiều:

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

Tuy nhiên, tôi lo ngại về một thứ như thế này.

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

Bằng cách này bất cứ khi nào trường hợp là 0, 1, nó sẽ thực hiện mọi thứ trong câu lệnh switch. Tôi đã thấy điều này theo thiết kế và tôi chỉ không biết liệu tôi có đồng ý rằng các câu lệnh switch nên được sử dụng theo cách này hay không. Tôi nghĩ ví dụ mã đầu tiên là một ví dụ rất hữu ích và an toàn. Điều thứ hai có vẻ nguy hiểm.

Nó có thể phụ thuộc vào những gì bạn cho là dự phòng. Tôi ổn với loại điều này:

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

Nhưng nếu bạn có một nhãn trường hợp theo sau là mã chuyển sang một nhãn trường hợp khác, tôi sẽ luôn coi đó là điều ác. Có lẽ chuyển mã chung sang một hàm và gọi từ cả hai nơi sẽ là một ý tưởng tốt hơn.

Và xin lưu ý rằng tôi sử dụng định nghĩa Câu hỏi thường gặp trong C ++ về "cái ác"

Đó là một con dao hai lưỡi. Nó đôi khi rất hữu ích, nhưng thường nguy hiểm.

Khi nào thì tốt? Khi bạn muốn 10 trường hợp được xử lý theo cùng một cách ...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

Một quy tắc mà tôi thích là nếu bạn từng làm bất cứ điều gì lạ lùng mà bạn loại trừ thời gian nghỉ, bạn cần có một nhận xét rõ ràng / * FALLTHROUGH * / để cho biết đó là ý định của bạn.

Bạn đã nghe nói về thiết bị của Duff chưa? Đây là một ví dụ tuyệt vời về việc sử dụng dự phòng chuyển đổi.

Đó là một tính năng có thể được sử dụng và nó có thể bị lạm dụng, giống như hầu hết các tính năng ngôn ngữ.

Vượt qua thực sự là một điều hữu ích, tùy thuộc vào những gì bạn đang làm. Hãy xem xét cách sắp xếp các tùy chọn gọn gàng và dễ hiểu này:

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

Hãy tưởng tượng làm điều này với if / else. Nó sẽ là một mớ hỗn độn.

Nó có thể rất hữu ích trong một vài lần, nhưng nói chung, không có hành vi nào là hành vi mong muốn. Rơi qua nên được cho phép, nhưng không ngầm.

Ví dụ, để cập nhật phiên bản cũ của một số dữ liệu:

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

Tôi thích một cú pháp khác cho các dự phòng trong công tắc, đại loại như, err ..

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

Lưu ý: Điều này đã có thể thực hiện được với enum, nếu bạn khai báo tất cả các trường hợp trên enum của mình bằng cách sử dụng cờ, phải không? Nghe cũng không tệ lắm; các trường hợp có thể (nên?) rất tốt là một phần của enum của bạn rồi.

Có lẽ đây sẽ là một trường hợp tốt (không có ý định chơi chữ) cho một giao diện thông thạo sử dụng các phương pháp mở rộng? Một cái gì đó như, errr ...

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

Mặc dù điều đó có lẽ thậm chí còn ít đọc hơn: P

Như với bất cứ thứ gì: nếu được sử dụng cẩn thận, nó có thể là một công cụ tao nhã.

Tuy nhiên, tôi nghĩ rằng những hạn chế hơn là biện minh cho việc không sử dụng nó, và cuối cùng là không cho phép nó nữa (C #). Trong số các vấn đề là:

• thật dễ dàng để "quên" thời gian nghỉ ngơi
• Không phải lúc nào những người bảo trì mã cũng rõ ràng rằng một lỗi bị bỏ qua là cố ý

Sử dụng tốt công tắc / trường hợp dự phòng:

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

Baaaaad sử dụng một công tắc / trường hợp dự phòng:

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

Điều này có thể được viết lại bằng cách sử dụng cấu trúc if / else mà không mất mát gì theo ý kiến ​​của tôi.

Lời cuối cùng của tôi: hãy tránh xa các nhãn viết hoa như trong ví dụ xấu , trừ khi bạn đang duy trì mã kế thừa nơi phong cách này được sử dụng và hiểu rõ.

Nó mạnh mẽ và nguy hiểm. Vấn đề lớn nhất đối với sự chuyển giao là nó không rõ ràng. Ví dụ: nếu bạn bắt gặp mã được chỉnh sửa thường xuyên có một nút chuyển với các lỗi, làm thế nào bạn biết đó là cố ý chứ không phải lỗi?

Bất kỳ nơi nào tôi sử dụng nó, tôi đảm bảo rằng nó được nhận xét đúng:

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

Sử dụng cú ngã như trong ví dụ đầu tiên của bạn rõ ràng là OK, và tôi sẽ không coi đó là một cú rơi thực sự.

Ví dụ thứ hai là nguy hiểm và (nếu không được bình luận rộng rãi) không rõ ràng. Tôi dạy học sinh của mình không sử dụng các cấu trúc như vậy trừ khi họ cho rằng việc dành một khối bình luận cho nó là xứng đáng, trong đó mô tả rằng đây là một sự cố ý và tại sao giải pháp này tốt hơn các giải pháp thay thế. Điều này không khuyến khích việc sử dụng cẩu thả, nhưng nó vẫn được phép sử dụng trong những trường hợp được sử dụng để làm lợi thế.

Điều này ít nhiều tương đương với những gì chúng tôi đã làm trong các dự án không gian khi ai đó muốn vi phạm tiêu chuẩn mã hóa: họ phải nộp đơn xin cấp phép (và tôi đã được gọi để tư vấn về phán quyết).

Tôi không thích các switchtuyên bố của mình bị bỏ sót - nó quá dễ xảy ra lỗi và khó đọc. Ngoại lệ duy nhất là khi nhiều casecâu lệnh cùng làm một việc chính xác .

Nếu có một số mã chung mà nhiều nhánh của câu lệnh switch muốn sử dụng, tôi trích xuất mã đó thành một hàm chung riêng có thể được gọi trong bất kỳ nhánh nào.

Trong một số trường hợp, việc sử dụng các bước chuyển tiếp là một hành động lười biếng của lập trình viên - họ có thể sử dụng một loạt || chẳng hạn như câu lệnh, nhưng thay vào đó sử dụng một loạt các trường hợp chuyển đổi 'bắt tất cả'.

Điều đó đang được nói, tôi thấy chúng đặc biệt hữu ích khi tôi biết rằng cuối cùng tôi vẫn cần các tùy chọn (ví dụ: trong một phản hồi menu), nhưng vẫn chưa thực hiện tất cả các lựa chọn. Tương tự như vậy, nếu bạn đang thực hiện chuyển đổi cho cả 'a' và 'A', tôi thấy việc sử dụng chuyển đổi chuyển đổi về cơ bản rõ ràng hơn là lệnh if ghép.

Đó có thể là vấn đề về phong cách và cách các lập trình viên suy nghĩ, nhưng tôi thường không thích loại bỏ các thành phần của một ngôn ngữ dưới danh nghĩa 'an toàn' - đó là lý do tại sao tôi hướng tới C và các biến thể / hậu duệ của nó hơn là, Java. Tôi thích có thể tìm hiểu xung quanh với các con trỏ và những thứ tương tự, ngay cả khi tôi không có "lý do" để làm.

Fall-through chỉ nên được sử dụng khi nó được sử dụng như một bảng nhảy vào một khối mã. Nếu có bất kỳ phần nào của mã có dấu ngắt không điều kiện trước nhiều trường hợp hơn, tất cả các nhóm trường hợp sẽ kết thúc theo cách đó.

Còn gì nữa là "ác".