Tôi có nên sử dụng dấu ngoặc đơn trong các câu lệnh logic ngay cả khi không cần thiết?

Giả sử tôi có một điều kiện boolean a AND b OR c AND dvà tôi đang sử dụng một ngôn ngữ ANDcó tiền lệ hoạt động cao hơn so với OR. Tôi có thể viết dòng mã này:

If (a AND b) OR (c AND d) Then ...

Nhưng thực sự, điều đó tương đương với:

If a AND b OR c AND d Then ...

Có bất kỳ đối số trong hoặc chống lại bao gồm cả dấu ngoặc đơn không? Có kinh nghiệm thực tế cho thấy rằng nó có giá trị bao gồm chúng cho khả năng đọc? Hay đó là một dấu hiệu cho thấy một nhà phát triển cần phải thực sự ngồi xuống và tự tin vào những điều cơ bản trong ngôn ngữ của họ?

Các nhà phát triển giỏi cố gắng viết mã rõ ràng và chính xác . Dấu ngoặc trong điều kiện, ngay cả khi chúng không được yêu cầu nghiêm ngặt, giúp cả hai.

Để rõ ràng , hãy nghĩ về dấu ngoặc đơn như nhận xét trong mã: chúng không thực sự cần thiết và về lý thuyết, một nhà phát triển có thẩm quyền sẽ có thể tìm ra mã mà không có chúng. Tuy nhiên, những tín hiệu này cực kỳ hữu ích, bởi vì:

• Họ giảm công việc cần thiết để hiểu mã.
• Họ cung cấp xác nhận về ý định của nhà phát triển.

Hơn nữa, các dấu ngoặc đơn bổ sung, giống như các vết lõm, khoảng trắng và các tiêu chuẩn kiểu khác, giúp tổ chức trực quan mã theo cách hợp lý.

Đối với tính chính xác , điều kiện không có dấu ngoặc đơn là một công thức cho những sai lầm ngớ ngẩn. Khi chúng xảy ra, chúng có thể là những lỗi khó tìm - bởi vì thường thì một điều kiện không chính xác sẽ hành xử chính xác hầu hết thời gian và chỉ thỉnh thoảng thất bại.

Và ngay cả khi bạn hiểu đúng, người tiếp theo làm việc với mã của bạn có thể không, thêm lỗi vào biểu thức hoặc hiểu sai logic của bạn và do đó thêm lỗi ở nơi khác (như LarsH chỉ ra đúng).

Tôi luôn sử dụng dấu ngoặc đơn cho các biểu thức kết hợp andvà or(và cả cho các phép toán số học với các vấn đề ưu tiên tương tự).

Nó ít quan trọng cho dù bạn có tự tin trong việc nắm bắt ngôn ngữ hay không. Điều quan trọng hơn là việc nắm bắt ngôn ngữ của n00b theo bạn.

Viết mã của bạn theo cách rõ ràng nhất rõ ràng nhất có thể. Phụ huynh thường xuyên (nhưng không phải luôn luôn) giúp đỡ. Chỉ đưa ra một tuyên bố trên một dòng thường giúp. Sự nhất quán trong phong cách mã hóa thường giúp.

Có một điều giống như quá nhiều dấu ngoặc đơn, nhưng đó là một trong những tình huống mà bạn sẽ không cần lời khuyên - bạn sẽ biết điều đó khi bạn nhìn thấy nó. Tại thời điểm đó, cấu trúc lại mã của bạn để giảm độ phức tạp của câu lệnh thay vì loại bỏ dấu ngoặc đơn.

Đúng

Bạn phải luôn luôn sử dụng dấu ngoặc đơn ... bạn không kiểm soát thứ tự ưu tiên ... nhà phát triển trình biên dịch nào. Đây là một câu chuyện xảy ra với tôi về việc không sử dụng dấu ngoặc đơn. Điều này ảnh hưởng đến hàng trăm người trong khoảng thời gian hai tuần.

Lý do thực tế

Tôi đã sử dụng một ứng dụng khung chính. Một ngày nọ, khi trời trong xanh, nó ngừng hoạt động. Đó là ... nó chỉ dừng lại.

Công việc của tôi là làm cho nó hoạt động nhanh nhất có thể. Mã nguồn đã không được sửa đổi trong hai năm, nhưng đột nhiên nó chỉ dừng lại. Tôi đã cố gắng biên dịch mã và nó đã bị hỏng trên dòng XX. Tôi nhìn vào dòng XX và tôi không thể biết điều gì sẽ khiến dòng XX bị phá vỡ. Tôi yêu cầu thông số kỹ thuật chi tiết cho ứng dụng này và không có thông tin nào. Dòng XX không phải là thủ phạm.

Tôi đã in mã ra và bắt đầu xem xét nó từ trên xuống. Tôi bắt đầu tạo ra một sơ đồ về những gì đang diễn ra. Mã này rất phức tạp, tôi thậm chí không thể hiểu được nó. Tôi đã từ bỏ cố gắng để lưu đồ nó. Tôi sợ thực hiện các thay đổi mà không biết sự thay đổi đó sẽ ảnh hưởng đến phần còn lại của quá trình như thế nào, đặc biệt là vì tôi không có thông tin chi tiết về những gì ứng dụng đã làm hoặc nơi nó nằm trong chuỗi phụ thuộc.

Vì vậy, tôi quyết định bắt đầu ở đầu mã nguồn và thêm whitespce và phanh dòng để làm cho mã dễ đọc hơn. Tôi nhận thấy, trong một số trường hợp, có những điều kiện kết hợp ANDvà ORkhông thể phân biệt rõ ràng giữa dữ liệu nào được chỉnh sửa ANDvà dữ liệu nào được chỉnh sửa OR. Vì vậy, tôi bắt đầu đặt dấu ngoặc đơn xung quanh ANDvà các ORđiều kiện để làm cho chúng dễ đọc hơn.

Khi tôi từ từ dọn dẹp nó, tôi sẽ định kỳ lưu công việc của mình. Tại một thời điểm tôi đã cố gắng biên dịch mã và một điều kỳ lạ xảy ra. Lỗi đã nhảy qua dòng mã ban đầu và bây giờ đã xuống sâu hơn. Vì vậy, tôi tiếp tục, bỏ qua các điều kiện ANDvà ORđiều kiện với parens. Khi tôi đã hoàn thành việc làm sạch nó, nó hoạt động. Đi hình.

Sau đó tôi quyết định ghé thăm cửa hàng hoạt động và hỏi họ xem gần đây họ có cài đặt bất kỳ thành phần mới nào trên khung chính không. Họ nói có, gần đây chúng tôi đã nâng cấp trình biên dịch. Hừm.

Nó chỉ ra rằng trình biên dịch cũ đánh giá biểu thức từ trái sang phải bất kể. Phiên bản mới của trình biên dịch cũng đánh giá các biểu thức từ trái sang phải nhưng mã mơ hồ, nghĩa là sự kết hợp không rõ ràng ANDvà ORkhông thể giải quyết được.

Bài học tôi học được từ điều này ... LUÔN LUÔN, LUÔN LUÔN, LUÔN LUÔN sử dụng parens cho các ANDđiều kiện và điều kiện riêng biệt ORkhi chúng được sử dụng để kết hợp với nhau.

Ví dụ đơn giản hóa

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(mã bị vấy bẩn với một vài trong số này)

Đây là phiên bản đơn giản hóa của những gì tôi gặp phải. Cũng có những điều kiện khác với các câu lệnh logic boolean ghép.

Tôi nhớ đã nhai nó để:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

Tôi không thể viết lại vì không có thông số kỹ thuật. Các tác giả ban đầu đã qua lâu. Tôi nhớ áp lực dữ dội. Toàn bộ tàu chở hàng bị mắc kẹt tại cảng và không thể tải được vì chương trình nhỏ này không hoạt động. Không có cảnh báo. Không có thay đổi đối với mã nguồn. Tôi chỉ nhận ra rằng tôi yêu cầu các hoạt động mạng nếu họ sửa đổi bất cứ điều gì sau khi tôi nhận thấy rằng việc thêm parens đã làm thay đổi các lỗi.

Có, nếu có hỗn hợp 'và' và 'hoặc'.

Ngoài ra ý tưởng tốt để () những gì là một kiểm tra logic.

Mặc dù tốt nhất là sử dụng các hàm vị ngữ được đặt tên tốt và loại bỏ hầu hết các kiểm tra và điều kiện ở đó, để lại nếu đơn giản và dễ đọc.

Các dấu ngoặc đơn là dư thừa về mặt ngữ nghĩa, vì vậy trình biên dịch không quan tâm, nhưng đó là một cá trích đỏ - mối quan tâm thực sự là khả năng đọc và hiểu của lập trình viên.

Tôi sẽ đảm nhận vị trí cấp tiến ở đây và nói "không" với các dấu ngoặc đơn trong a AND b OR c AND d. Mọi lập trình viên nên biết rằng sự ưu tiên trong các biểu thức Boolean KHÔNG> VÀ> HOẶC , giống như ghi nhớ Xin vui lòng Xin lỗi Dì thân mến của tôi cho các biểu thức đại số. Dấu câu thừa chỉ thêm lộn xộn thị giác hầu hết thời gian trong mã mà không có lợi ích trong khả năng đọc của lập trình viên.

Ngoài ra, nếu bạn luôn sử dụng dấu ngoặc đơn trong các biểu thức logic và đại số, thì bạn từ bỏ khả năng sử dụng chúng làm điểm đánh dấu cho "điều gì đó khó khăn đang xảy ra ở đây - xem ra!" Đó là, trong trường hợp bạn muốn ghi đè mức ưu tiên mặc định và được đánh giá bổ sung trước khi nhân hoặc OR trước AND, dấu ngoặc đơn là một cờ đỏ đẹp cho lập trình viên tiếp theo. Sử dụng chúng quá nhiều khi không cần thiết và bạn trở thành Cậu bé Sói khóc.

Tôi sẽ tạo một ngoại lệ cho bất cứ điều gì bên ngoài lĩnh vực đại số (Boolean hoặc không), chẳng hạn như các biểu thức con trỏ trong C, trong đó bất cứ điều gì phức tạp hơn các thành ngữ tiêu chuẩn như *p++hoặc p = p->nextcó lẽ nên được ngoặc đơn để giữ cho hội thảo và số học thẳng. Và, tất nhiên không điều nào trong số này áp dụng cho các ngôn ngữ như Lisp, Forth hoặc Smalltalk sử dụng một số dạng ký hiệu Ba Lan cho các biểu thức; nhưng đối với phần lớn các ngôn ngữ chính, ưu tiên logic và số học hoàn toàn được chuẩn hóa.

Theo tôi thấy:

CÓ Ưu điểm:

• Thứ tự của các hoạt động là rõ ràng.
• Bảo vệ bạn khỏi các nhà phát triển trong tương lai, những người không hiểu thứ tự hoạt động.

CÓ Nhược điểm:

• Có thể dẫn đến lộn xộn, khó đọc mã

KHÔNG Ưu điểm:

• ?

Không có khuyết điểm:

• Trình tự hoạt động là ẩn
• Mã ít được duy trì cho các nhà phát triển mà không hiểu rõ về thứ tự các hoạt động.

Có bất kỳ đối số trong hoặc chống lại bao gồm cả dấu ngoặc đơn không? Có kinh nghiệm thực tế cho thấy rằng nó có giá trị bao gồm chúng cho khả năng đọc? Hay đó là một dấu hiệu cho thấy một nhà phát triển cần phải thực sự ngồi xuống và tự tin vào những điều cơ bản trong ngôn ngữ của họ?

Nếu không ai khác phải xem lại mã của tôi, tôi không nghĩ mình sẽ quan tâm.

Nhưng, từ kinh nghiệm của tôi:

• Thỉnh thoảng tôi nhìn lại mã của mình (đôi khi nhiều năm sau khi viết nó)
• Những người khác đôi khi nhìn vào mã của tôi
  • Hoặc thậm chí phải mở rộng / sửa chữa nó!
• Cả tôi và người khác đều nhớ chính xác những gì tôi đã nghĩ khi viết nó
• Viết mã "tối thiểu hóa số ký tự" làm tổn thương khả năng đọc

Tôi hầu như luôn luôn làm điều này bởi vì tôi tin tưởng vào khả năng đọc nhanh và không mắc lỗi nhỏ nhiều hơn với parens hơn là không có gì khác.

Trong trường hợp của bạn, tôi gần như chắc chắn sẽ làm một cái gì đó như:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Vâng, đó là nhiều mã hơn. Vâng, tôi có thể làm toán tử bool ưa thích thay thế. Không, tôi không thích cơ hội khi lướt qua mã 1+ năm trong tương lai Tôi đọc sai các toán tử bool ưa thích. Điều gì xảy ra nếu tôi đang viết mã bằng một ngôn ngữ có quyền ưu tiên AND / OR khác nhau và phải quay lại để sửa lỗi này? Tôi sẽ đi đây, "aha! Tôi nhớ điều nhỏ bé thông minh này mà tôi đã làm! Tôi đã không bao gồm các parens khi tôi viết vào năm ngoái, điều tốt là tôi nhớ bây giờ!" nếu điều đó xảy ra (hoặc tệ hơn, một người nào khác không biết về sự thông minh này hoặc bị ném vào tình huống loại "sửa càng sớm càng tốt")?

Việc tách với () làm cho nó trở nên đơn giản hơn rất nhiều để nhanh chóng đọc lướt và hiểu sau ...

Trường hợp chung

Trong C #, phép nhân và phép chia có quyền ưu tiên hơn phép cộng và phép trừ.

Tuy nhiên, StyleCop, một công cụ thực thi kiểu phổ biến trên cơ sở mã với mục tiêu bổ sung để giảm thiểu rủi ro lỗi do mã giới thiệu có thể không đủ rõ ràng, có quy tắc SA1407 . Quy tắc này sẽ tạo ra một cảnh báo với một đoạn mã như thế này:

var a = 1 + 2 * 3;

Rõ ràng là kết quả là 7và không 9, nhưng vẫn, StyleCop đề nghị đặt dấu ngoặc đơn:

var a = 1 + (2 * 3);

Trường hợp cụ thể của bạn

Trong trường hợp cụ thể của bạn, có một ưu tiên AND so với OR trong ngôn ngữ cụ thể bạn sử dụng.

Đây không phải là cách mọi ngôn ngữ ứng xử. Nhiều người khác đối xử VÀ VÀ HOẶC như nhau.

Là một nhà phát triển làm việc chủ yếu với C #, khi tôi nhìn thấy câu hỏi của bạn lần đầu tiên và đọc đoạn mã mà không đọc những gì bạn đã viết trước đó, cám dỗ đầu tiên của tôi là nhận xét rằng hai biểu thức không giống nhau. Hy vọng rằng, tôi đã đọc toàn bộ câu hỏi trước khi bình luận.

Tính đặc biệt này và rủi ro mà một số nhà phát triển có thể tin rằng AND và OR có cùng mức độ ưu tiên khiến cho việc thêm dấu ngoặc đơn càng quan trọng hơn.

Đừng viết mã với mục tiêu để cho thấy rằng bạn thông minh. Viết mã với mục tiêu dễ đọc, bao gồm cả những người có thể không quen thuộc với mọi khía cạnh của ngôn ngữ.

Như mọi người đã nói, sử dụng dấu ngoặc đơn mỗi lần nó làm cho biểu thức dễ đọc hơn. Tuy nhiên, nếu biểu thức phức tạp, tôi khuyên bạn nên giới thiệu các chức năng mới cho các biểu thức con .

Hay đó là một dấu hiệu cho thấy một nhà phát triển cần phải thực sự ngồi xuống và tự tin vào những điều cơ bản trong ngôn ngữ của họ?

Nếu bạn nghiêm túc sử dụng ngôn ngữ ở số ít, có thể. Bây giờ, hãy sử dụng tất cả các ngôn ngữ bạn biết, từ cũ đến hiện đại nhất, từ được biên dịch sang viết mã thành SQL đến DSL của riêng bạn mà bạn đã phát minh ra vào tháng trước.

Bạn có nhớ các quy tắc ưu tiên chính xác cho từng ngôn ngữ này mà không cần tìm kiếm không?

"Tôi có nên sử dụng dấu ngoặc đơn trong các câu lệnh logic ngay cả khi không cần thiết."

Có, bởi vì hai người sẽ thấy chúng hữu ích:

• Lập trình viên tiếp theo, kiến ​​thức, năng lực hoặc phong cách có thể khác nhau

• Tương lai bạn trở lại mã này vào một ngày nào đó sau này!

Các điều kiện phức tạp là "đại số boolean", mà bạn viết theo một số cách, làm cho nó trông khá giống với đại số, và bạn chắc chắn sẽ sử dụng parens cho đại số , phải không?

Các quy tắc thực sự hữu ích là những quy tắc phủ định:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Hoặc, trong một định dạng rõ ràng hơn một chút:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

mà thực sự rõ ràng chỉ là đại số khi được viết là:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

Nhưng chúng ta cũng có thể áp dụng tư duy cho đơn giản hóa và mở rộng đại số:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

mặc dù trong mã bạn phải viết:

(A||C) && (B||C) && (A||D) && (B||D)

hoặc, trong một định dạng rõ ràng hơn một chút:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Về cơ bản, một điều kiện vẫn chỉ là một biểu thức đại số và bằng cách sử dụng dấu ngoặc đơn rõ ràng, bạn có thể dễ dàng áp dụng các quy tắc đại số khác nhau mà bạn đã biết vào biểu thức, bao gồm cả khái niệm "đơn giản hóa hoặc mở rộng công thức này".

Tôi sẽ sử dụng dấu ngoặc đơn ngay cả khi nó là tùy chọn, tại sao vì nó giúp hiểu rõ hơn cho mọi người, cho người viết mã cũng như người sẵn sàng xem mã đó. Trong trường hợp của bạn, ngay cả các toán tử boolean đã được ưu tiên, nó có thể hoạt động tốt lúc đầu, nhưng chúng tôi không thể nói rằng nó sẽ giúp bạn trong mọi trường hợp. Vì vậy, tôi thích sử dụng dấu ngoặc đơn của người dùng trong bất kỳ điều kiện nào mà nó có thể yêu cầu hoặc tùy chọn.

Đúng. Bạn nên sử dụng trong mọi trường hợp khi bạn cảm thấy mã của mình sẽ rõ ràng hơn. Hãy nhớ mã của bạn phải đủ rõ ràng để người khác có thể hiểu mà không cần đọc bình luận của bạn bên trong mã. Vì vậy, đó là một thực hành tốt để sử dụng dấu ngoặc đơn và niềng răng. Ngoài ra, hãy nhớ rằng nó có thể phụ thuộc vào thực tiễn cụ thể của công ty / nhóm của bạn. Chỉ cần duy trì một cách tiếp cận và không trộn lẫn.