tuyên bố chuyển đổi này có mùi không?

Question

Switch(some case) { 
    case 1: 
      // compute something ... 
      return something; 
      break; 
    case 2: 
      // compute something ... 
      return something; 
      break; 

/* some more cases ... */ 

    case X: 
      // compute something ... 
      return something; 
      break; 
    default: 
      // do something 
      return something; 
      break; 
} 

Theo tôi:

Giả sử câu lệnh switch này là chính đáng, sự trở lại và phá vỡ chỉ doesnt nhìn bên phải hoặc cảm thấy đúng.

Nghỉ giải lao rõ ràng là không cần thiết, nhưng kiểu bỏ sót kém (hoặc kiểu này kém để bắt đầu?)?

---

Cá nhân tôi không làm điều này, nhưng có một số điều này trong codebase tại nơi làm việc. Và không, im sẽ không tự chính niệm và sửa mã nguồn.

Answer 1

Trình biên dịch C# đưa ra cảnh báo nếu bạn làm điều này nói rằng ngắt là mã không thể truy cập được. Vì vậy, trong cuốn sách của tôi nó là hình thức xấu để có cả hai trở lại và phá vỡ.

Answer 2

Theo ý kiến ​​của tôi, tôi sẽ bỏ qua từ khóa 'ngắt'. Cá nhân tôi nghĩ rằng nó giúp nhắc nhở mọi người rằng 'Thực hiện đã kết thúc! Không có gì nhiều để xem ở đây!'.

Answer 3

tôi sẽ làm một sự thay đổi nhỏ:

switch(some case) { 
    case 1: 
      // compute something ... 
      break; 
    case 2: 
      // compute something ... 
      break; 
/* some more cases ... */ 
    case X: 
      // compute something ... 
      break; 
    default: 
      // do something 
      break; 
} 
return something; 

Answer 4

Không, thiếu sót không phải là phong cách nghèo - bao gồm là phong cách của người nghèo. Đó là những tuyên bố không thể truy cập được. Loại bỏ chúng.

Tôi thích thực tế là các trường hợp quay trở lại trực tiếp thay vì đặt biến địa phương và sau đó quay lại ở dưới cùng - điều đó có nghĩa là nó cực kỳ rõ ràng khi bạn đang đọc mã số đó không chỉ cần trả lại, và đó là tất cả.

Side-lưu ý về chuyển đổi ở nơi đầu tiên:

Đối với việc sử dụng một câu lệnh switch là điều đúng đắn nên làm ở đây, nó thực sự phụ thuộc vào những thứ khác. Nó sẽ có ý nghĩa để sử dụng một loại đa hình thay vào đó? Nếu bạn đang sử dụng Java, bạn có thể sử dụng enum thông minh không? (Bạn có thể bắt chước chúng trong C#, nhưng không có nhiều hỗ trợ.)

Tôi muốn nói điều này ít nhất phải nhắc xem xét thiết kế khác nhau - nhưng nó cũng là cách đơn giản nhất để làm những gì bạn muốn .

Answer 5

Mùi mã ngụ ý một vấn đề thiết kế. Đây chỉ là vấn đề định dạng. Tôi nghĩ rằng hầu hết mọi người sẽ đồng ý rằng một phiên bản bị ngắt bỏ qua là cấp trên.

Answer 6

Ngắt là dư thừa.

Một số quy tắc chung, Chỉ nên thoát một hàm ở một nơi duy nhất, nhưng vì quy tắc này đã được thực hiện, Try-Catch được phát minh (oop goto).

Nếu bạn giữ cùng một kiểu trên ứng dụng của mình, tôi đoán bạn có thể sống với sự trở lại trong nút chuyển.

Answer 7

Tôi không chắc chắn như thế nào đen mã mà được thiết kế để được như vậy một số những quan sát này không thể áp dụng ...

"trường hợp 1" Nếu bạn numers thực sự cứng mã hóa như tôi này nghĩ rằng đó là phong cách nghèo nàn và bạn nên xem xét sử dụng một điều tra.

Nếu bạn chỉ đơn giản trả lại nội dung nào đó và không có logic bổ sung trong tập hợp con, bạn có thể xem xét đặt "somethings" trong mảng hoặc từ điển và chỉ đơn giản là giải quyết chúng bằng chỉ mục thay vì sử dụng câu lệnh switch. ..

trả về các thứ [chỉ]

Answer 8

Mùi mã ở đây là các giá trị được mã hóa cứng trong báo cáo trường hợp.

Đối với lợi nhuận, đó là câu hỏi về sở thích và đánh giá tốt hơn. Chắc chắn nếu trường hợp của bạn kéo dài các trang mutiple nó dễ dàng hơn để đọc nếu sự trở lại là trong trường hợp, nhưng sau đó vấn đề là chuyển đổi lớn để bắt đầu với.

Personnaly Tôi thích tùy chọn trả về đơn nhất vì nếu bạn cần thêm một số quy trình xử lý thì việc tái cấu trúc lại rẻ hơn so với tất cả các trường hợp. Ngoài ra, nếu được trao cho người khác để tái cấu trúc họ sẽ không có sự cám dỗ để sao chép dán mã trong mọi trường hợp, ít nhất tôi sẽ hy vọng như vậy ... nếu họ làm họ tốt hơn hy vọng tôi không phải là người làm xét lại mã của họ (cho sao chép dán rõ ràng).

Answer 9

Báo cáo chuyển đổi là bản thân mã nguồn. Theo các dòng của những gì l99057j nói, nếu tất cả những gì bạn đang làm là ánh xạ đầu vào cho các giá trị không đổi, đây là một vị trí cho một cấu trúc tra cứu thích hợp, chẳng hạn như mảng/danh sách cho đầu vào tuần tự hoặc từ điển/bản đồ cho một thưa thớt, không phải là một tuyên bố chuyển đổi. Nếu bạn đang tính toán một cái gì đó, thì giá trị sẽ là một đại biểu mà bạn gọi với đầu vào.

Answer 10

Những người khác đã nhận xét về các khía cạnh khác. Đối với những sự phá vỡ dư thừa sau khi trả về: Tôi sẽ GIỮ họ, cùng một lý do như {} xung quanh một câu lệnh duy nhất nếu cơ thể: nó phải là bản chất thứ hai cho mọi lập trình viên để đặt những chiếc braks đó. Tốt hơn nên có 100 lần nghỉ ngơi dư thừa hơn một lần vô tình bị mất tích.