Tại sao lại xuất hiện thụt đầu dòng kỳ lạ trên các câu lệnh switch?


77

Tại sao thiếu dấu thụt lề imho của "case" - từ khóa trong câu lệnh switch được coi là kiểu tốt?

Từ khóa "trường hợp" không thụt lề có vẻ là tùy chọn định dạng mặc định trong mọi IDE:

switch (i){
case 0:
    break;
case 1:
    break;
}

trong khi tôi thấy định dạng này trực quan hơn:

switch (i){
    case 0:
        break;
    case 1:
        break;
}

Có một số logic đằng sau điều này, mà trốn tránh tôi?


2
Không nhận ra điều này cho đến bây giờ! Có lẽ vì công tắc được phát minh trước khi thụt đầu dòng))
Rodion

1
NB không thụt lề chuyển đổi theo mặc định (và có vẻ dễ đọc hơn đối với tôi quá)
barti_ddu



1
@gstackoverflow IDEA 15.0.5 nó không làm điều đó cho tôi. Tôi ước nó đã làm. Tôi thích thụt lề tương ứng với các nhóm logic và công tắc là một phần tử logic, các tác động của nó thường muốn coi là một đơn vị. Vì vậy, tôi muốn xem nó như một đơn vị (ví dụ như thụt lề). Tôi cũng có xu hướng thêm dấu ngoặc nhọn xung quanh các câu lệnh cho các phần trường hợp.
Gus

Câu trả lời:


55

Các trường hợp là nhãn hợp lý. Nhiều người đặt nhãn ở cùng mức thụt lề như khối mà họ đang ở. Theo tôi, bằng cách đó, văn bản sẽ dễ đọc hơn.

Tôi so sánh nó với một dòng thời gian mà bạn có thể cuộn qua. Bạn có các điểm đánh dấu trên dòng thời gian, không được thụt vào nội dung. Sau đó, bạn có thể nhanh chóng chỉ ra vị trí của các nhãn / điểm đánh dấu mà không cần di chuyển mắt khỏi đường cơ sở.


11
Nói cách khác, nội dung của switchkhối được thụt vào một cấp so với switchchính nó, nhưng các khối caseđược "lấn át" một cấp so với mã mà chúng được trộn vào.
Steve Jessop

Tôi đã ở trong hàng rào về điều này, nghiêng về việc thụt lề vì tôi nghĩ rằng nó dễ đọc hơn một chút. Câu trả lời này, cùng với lợi ích của việc ngăn chặn quá nhiều thụt lề / quấn, đã thay đổi quan điểm của tôi. Việc coi các trường hợp là nhãn thay vì các điều kiện dường như giúp dễ đọc hơn một chút khi không bị thụt lề.
Pilot_51

2
Các casephần hoạt động giống như nhãn trong đó luồng thực thi sẽ tiến hành thông qua nhãn từ mã bên trên đến mã bên dưới mà không có a break. Tôi vẫn thích nhìn thấy chúng được thụt vào. Đối với mắt tôi, không có vết lõm, nó ẩn đi switchchính bản thân câu lệnh, khiến chúng ta khó nhìn thấy sự việc bắt đầu. Nhưng đây chỉ là một vấn đề thực sự khi có quá nhiều trường hợp và đó là một vấn đề hoàn toàn khác.
Lee Meador

Điều gì về mệnh đề mặc định? Trong Eclipse (Java), trường hợp mặc định của công tắc được tự động thụt vào, nó không phải là "không được làm lõm" như các trường hợp. Tôi nghĩ rằng khả năng dễ đọc đối với những gì xảy ra trong các trường hợp mặc định tương đương với nhu cầu về khả năng đọc trong các trường hợp xác định.
Chexxor

1
Nếu bạn cũng niềng răng casethì sao? Bạn sẽ kết thúc với 2 dấu ngoặc nhọn đóng ở cùng một mức thụt vào trên các dòng khác nhau.
Iulian Onofrei

28

Trong 4 từ: không khối, không thụt lề .

Các trường hợp không mở một khối. Trong C hoặc C ++, bạn thậm chí có thể đặt các khai báo biến (nhưng các trình khởi tạo không được gọi, ngoại trừ các biến tĩnh, đó là một cạm bẫy) ở đầu khối chuyển đổi. Bạn có thể làm nhiều điều kỳ lạ với switch, chẳng hạn như thiết bị của Duff .

Do đó, vì các trường hợp chỉ là nhãn, thụt lề cho chúng có vẻ không trực quan và không thụt lề là kiểu được hầu hết các kiểu lựa chọn.


Tôi sẽ không nói rằng chúng nhất thiết phải là nhãn, bởi vì bạn có thể nghĩ chúng vừa là nhãn vừa là đường cú pháp cho một chuỗi các if-elses. Mặc dù, vì chúng trông giống như nhãn nên có thể cách thụt lề phù hợp hơn theo cách đó.
rodion

28
Tôi không nghĩ rằng quy tắc đó mô tả phong cách được đề cập. switchgiới thiệu một khối, và casekhông. Và casedường như giới thiệu một cấp độ thụt lề mới, trong khi switchkhông.
Steve Jessop

1
@rodion: về độ phức tạp, các triển khai chuyển mạch C là O (1) và các chuỗi if-else tương đương là O (n). if-else dự kiến ​​sẽ được theo sau bởi chính xác một câu lệnh, không phải chữ hoa chữ thường, v.v. Bạn cũng có thể tìm thấy các tham chiếu đến các trường hợp dưới dạng nhãn trong tiêu chuẩn C (không kiểm tra báo giá chính xác, nhưng tôi khá chắc rằng mình đã thấy ).
kriss

@Steve: switchkhông tự giới thiệu một khối. Nó chỉ là câu lệnh khối mà mọi người thường sử dụng như câu lệnh phụ thuộc giới thiệu khối.
Jens Gustedt

1
@kriss: Tất cả các khai báo biến tự động đều là định nghĩa. Chúng chỉ không được khởi tạo. Không có hại gì khi đặt các định nghĩa biến đã khởi tạo vào đầu một công tắc, nhưng quá trình khởi tạo sẽ không bao giờ được thực hiện, vì vậy nó vô ích. Tất nhiên, các định nghĩa biến tĩnh có hiệu lực khi bắt đầu chuyển đổi, bất kể chúng có được khởi tạo hay không.
R .. GitHub NGỪNG TRỢ GIÚP ICE

11

Quy ước Mã Oracle chính thức năm 1999 cho Ngôn ngữ Lập trình Java TM (mục 7.8) đề xuất một kiểu chuyển đổi trong đó các câu lệnh trường hợp không được thụt vào so với toàn bộ câu lệnh switch.

Đây là một sự lựa chọn chủ quan, nhưng Sun đã quyết định rằng tốt hơn hết nếu mọi người theo một phong cách và chọn phong cách này.


Hừ! Seig heil!
Rex the Strange

4

Có nhiều kiểu thụt lề khác nhau để lựa chọn. AFAIK, không có kiểu nào được coi là tốt hơn những kiểu khác miễn là bạn luôn sử dụng kiểu thụt lề. Đối với tôi, thụt casenhãn là dễ đọc hơn, cùng đi cho private, protectedpublicnhãn trong các lớp học, tuy nhiên, IDE của tôi sẽ không làm thụt đầu dòng cách của tôi. Mã của tôi không thể đọc được vì tôi muốn nó theo cách này. Mà thôi ...


3
tương tự cho tôi, tôi thực sự ghét trường hợp không thụt vào, được lập trình cho 20 năm, nhưng tôi cũng có thể mua nó là một vấn đề chủ quan ...
rupps

4

Có thể nó là để giữ cùng một mức độ thụt lề như tương đương logic của nó được thể hiện trong các trạng thái if? Đó là:

switch(i){
case 0:
  //do something 1
case 1:
  //do something 2
}

Sẽ giống với tương đương logic của nó:

if(i==0){
  //do something 1
}else if(i==1){
  //do something 2
}

2
Có lẽ là không - switch / case thường được thực hiện bởi jumptable nếu có thể, không phải if / else rắn.
Johan Kotlinski

0

FWIW, một tùy chọn khác đang sử dụng hai nửa thụt lề:

switch (i) {
  case 1:
    ...
  case n:
    ...
}
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.