Các trường hợp chuyển đổi Java: có hay không có dấu ngoặc nhọn?


85

Hãy xem xét hai đoạn mã sau, có dấu ngoặc nhọn:

switch (var) {
  case FOO: {
    x = x + 1;
    break;
  }

  case BAR: {
    y = y + 1;
    break;
  }
}

Không có niềng răng:

switch (var) {
  case FOO:
    x = x + 1;
    break;

  case BAR:
    y = y + 1;
    break;
}

Tôi biết rằng, trong đoạn mã có dấu ngoặc nhọn, một phạm vi mới được tạo bằng cách đặt từng trường hợp trong dấu ngoặc nhọn. Tuy nhiên, nếu mỗi trường hợp không cần phạm vi mới (tức là không có tên biến nào được sử dụng lại), thì có loại hình phạt hiệu suất nào cho việc sử dụng dấu ngoặc nhọn với một trường hợp không?

Câu trả lời:


99

có bất kỳ hình phạt hiệu suất nào cho việc sử dụng niềng răng với một trường hợp?

Không ai.

Các dấu ngoặc nhọn ở đó để giúp trình biên dịch tìm ra phạm vi của một biến, điều kiện, khai báo hàm, v.v. Nó không ảnh hưởng đến hiệu suất thời gian chạy khi mã được biên dịch thành tệp thực thi.


21

Không có hình phạt hiệu suất từ ​​quan điểm thực hiện.

Hình phạt hiệu suất nhẹ từ quan điểm biên dịch vì có nhiều thứ hơn để phân tích cú pháp, nhưng nếu bất kỳ ai thực sự lo lắng về điều đó, họ sẽ phải viết tất cả mã của họ trên một dòng :-)

Và bây giờ đối với phần ý kiến ​​của bài đăng của chúng tôi ... tôi luôn đặt {và} bởi vì có một hình phạt cho khả năng bảo trì mà bạn có thể sẽ phải đưa chúng vào một ngày sau đó và có thể rất khó khăn khi đặt chúng sau này ... nhưng đó là 103% sở thích cá nhân.


Tôi hơi tò mò vì tôi không thể tự mình thấy câu trả lời ... @TofuBeer, khi nào thì bạn PHẢI thêm niềng răng? Ngoài ra, tôi hoàn toàn đồng ý với quan điểm về khả năng bảo trì, tôi chỉ không thấy ATM có vấn đề về khả năng bảo trì. CHỈNH SỬA: đừng bận tâm. Tôi chỉ đọc phần còn lại của câu trả lời bên dưới.
nyaray

Bạn làm trong C ++ trong một số trường hợp, vì vậy nếu bạn làm việc bằng cả hai ngôn ngữ, bạn không nên mắc phải cả hai ngôn ngữ này.
TofuBeer

13

Như chúng ta đã biết niềng răng đối với các trường hợp chuyển đổi là không cần thiết. Sử dụng các ca niềng răng có thể gây ra sự nhầm lẫn về phạm vi của một ca.

Dấu ngoặc nhọn mở thường được liên kết với một cái gì đó có ý nghĩa như bắt đầu một hàm hoặc bắt đầu một vòng lặp hoặc bắt đầu khai báo lớp hoặc bắt đầu khởi tạo mảng, v.v. Chúng ta biết rằng, một trường hợp thoát ra khỏi khối chuyển đổi khi nó gặp một dấu ngắt tuyên bố. Do đó, việc sử dụng dấu ngoặc nhọn dường như ngụ ý về một phạm vi khác cho trường hợp đối với một người đọc thiếu hiểu biết. Vì vậy, tốt hơn hết là bạn nên tránh sử dụng dấu ngoặc nhọn vì lợi ích của việc lập trình dễ đọc hơn.

tức là Khi tôi có một cái gì đó như,

switch(i)
{
  case 1 :
  {
     //do something
  }
  System.out.println("Hello from 1");

  case 2: 
  ....
}

"Xin chào từ 1" được in. Nhưng việc sử dụng dấu ngoặc nhọn có thể gợi ý cho người đọc không biết rằng trường hợp kết thúc bằng '}', đã biết dấu ngoặc nhọn thường biểu thị điều gì trong trường hợp vòng lặp, phương thức, v.v.

Giống như chúng ta có các câu lệnh jump-to-label trong 'C', điều khiển chỉ thay đổi theo trường hợp và tiếp tục thực thi. Vì vậy, với sự hiểu biết đó, việc sử dụng dấu ngoặc nhọn khi viết các trường hợp cho switch chỉ là một điều BAD.

Về mặt kỹ thuật, bạn có thể bao quanh bất kỳ khối mã nào của mình bằng một cặp dấu ngoặc nhọn bổ sung khi được sử dụng với cú pháp hợp lệ. Sử dụng niềng răng trong chuyển đổi có vẻ rất tệ ít nhất đối với tôi vì nó dường như mang lại cảm giác khác như tôi đã nói ở trên.

Đề nghị của tôi: Chỉ cần tránh sử dụng các mắc cài xung quanh cho các trường hợp chuyển đổi.


5
Không đồng ý với điều này. Sử dụng dấu ngoặc nhọn VÀ viết mã bên ngoài dấu ngoặc nhọn sẽ rất tệ, đúng vậy, nhưng điều này không làm mất uy tín của bản thân việc sử dụng dấu ngoặc nhọn.
Max Roncace

12

Với niềng răng.

Có rất nhiều điều có thể xảy ra với các câu lệnh chuyển đổi, tôi cố gắng tránh chúng khi có thể, tức là

  1. Quên thời gian nghỉ và do đó có các trường hợp lọt
  2. Quên một trường hợp mặc định và do đó không bắt một trường hợp không phục vụ cho điều kiện
  3. Vô tình sử dụng lại các biến giữa các câu lệnh trường hợp, hoặc tệ hơn, ảnh hưởng đến một biến IS đang chia sẻ một biến giữa các câu lệnh trường hợp.

Sử dụng dấu ngoặc nhọn là một cách để ngăn chặn việc chia sẻ biến cố ý và ngẫu nhiên giữa các câu lệnh trường hợp


8
Bao gồm cả điểm 1 và 2 đã gây hiểu lầm cho câu hỏi này (đối với tôi); dòng kết thúc của bạn nên nói rõ ràng rằng niềng răng chỉ giải quyết được 3 - Tôi nghĩ rằng bạn có nghĩa là niềng răng loại trừ nhu cầu nghỉ, sau đó hãy thử nó.
ataulm

Điểm 3 thậm chí không có ý nghĩa. Bạn không thể sử dụng lại các biến trừ khi chúng được khai báo trong phạm vi cha của câu lệnh switch. Điều này có nghĩa là nếu bạn khai báo một biến trong một trường hợp, thì nó không thể được sử dụng trong một câu lệnh trường hợp khác. Nếu bạn khai báo một biến phía trên câu lệnh switch (trong phạm vi cha) thì không quan trọng bạn có sử dụng dấu ngoặc nhọn hay không, các câu lệnh case sẽ có quyền truy cập vào biến.
dsingleton

Tôi vừa (lại) phát hiện ra rằng các biến được khai báo trong trường hợp 1 vẫn có thể nằm trong phạm vi trong trường hợp 2. Ví dụ: ...case 1: int a = 10; break; case 2: int a = 11; break; ...không biên dịch. (đã thử nghiệm với Oracle JDK 8)
anuragw

5

Câu hỏi này có lẽ sẽ được đóng lại là "tranh luận" (BRACE WAR!) Nhưng cái quái gì vậy. Tôi thực sự thích niềng răng sau các trường hợp. Đối với tôi, nó làm cho cú pháp chuyển đổi xấu xí trông giống như phần còn lại của cấu trúc ngôn ngữ. (Không có hình phạt cho việc sử dụng dấu ngoặc nhọn trong "trường hợp" này)


Tôi đoán đó là loại một câu hỏi khách quan ... Tôi rút lại điều tranh luận
Andy trắng

Tôi thích nó hơn mà không cần niềng răng ... Tôi thấy niềng răng thêm nhiều tiếng ồn không cần thiết.
cdmckay

Vâng, tôi ước nó giống như thế này: case (FOO) {x = x + 1} case (BAR) {y = y + 1}
Andy White

Khoảng trắng hợp lý == tốt. Niềng răng không cần thiết == tút.
Shog9

3
khoảng trắng == kết hợp các tab và khoảng trắng == hút (tôi chỉ nghĩ rằng tôi sẽ ném một tab so với nhận xét khoảng cách vào hỗn hợp)
Andy White

5

Bạn nói rằng dấu ngoặc nhọn có thể được bỏ qua vì không có tên biến nào được sử dụng lại. Bằng cách sử dụng lại tên biến, tôi cho rằng bạn muốn khai báo một biến mới cùng kiểu.

Các niềng răng thực sự hữu ích nhất để đảm bảo bạn không sử dụng lại cùng một biến số khác nhau casedo nhầm lẫn. Họ không khai báo bất kỳ biến nào ngày hôm nay, nhưng ai đó sẽ thêm chúng vào ngày mai và không có dấu ngoặc nhọn, mã dễ bị lỗi.


3

Tôi sẽ không sử dụng niềng răng cho các trường hợp chuyển đổi.

  • Câu lệnh switch trông đủ baroque mà không cần dấu ngoặc nhọn.

  • Trường hợp chuyển mạch phải rất ngắn. Khi bạn cần khai báo các biến thì đó là dấu hiệu cho thấy bạn đang làm sai.

Bây giờ, hãy duy trì một số mã C kế thừa có các trường hợp chuyển đổi thể thao hơn 500 dòng ...


1

Tôi chưa bao giờ nghĩ về nó trước đây. Không bao giờ cần các dấu ngoặc nhọn trong một mệnh đề trường hợp vì vậy không thể thực sự hiểu tại sao bạn sẽ cần chúng. Cá nhân tôi không ủng hộ ý tưởng "Sẽ dễ dàng hơn để duy trì", đó chỉ là rác rưởi, sẽ dễ dàng hơn để duy trì nếu mã có ý nghĩa và được ghi lại.

Không có dấu ngoặc nhọn ... ít cú pháp hơn là nhiều


{và} cũng làm cho mọi thứ nổi bật, giúp dễ đọc hơn (IMO).
TofuBeer

vâng. Tôi đã định chia sẻ một câu chuyện về một phương pháp mà tôi đã từng phải sửa đổi (tôi mất khoảng 4 giờ để thêm một dòng mã) nhưng mã quá điên rồ (dài khoảng 10 trang và rộng 4 trang khi in) nên nó không trường hợp điển hình. Nhưng nếu nó được sử dụng {} thì sẽ mất một phút để thêm nó.
TofuBeer

Tôi nghĩ vấn đề ở đây là nếu lập trình viên ban đầu đã nỗ lực đưa vào các khối {} để mã dễ đọc hơn thì họ có thể thực sự quan tâm đến việc họ viết câu lệnh chuyển đổi 10 trang và thay đổi mã thành bớt điên rồ hơn một chút
Gareth Davis

swtich hẳn là một giấc mơ .. nó được lồng vào nhau nếu / elses ... được viết bằng mã C ++ bởi các lập trình viên COBOL ... Tôi bỏ việc không lâu sau đó.
TofuBeer
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.