Khi nào đánh giá ngắn mạch là xấu?

Nói rõ hơn một chút, tôi sẽ nói rằng tôi đã dành nhiều thời gian với các ngôn ngữ khác nhau. Nhưng cho đến bây giờ, nó sẽ sử dụng nó mọi lúc hoặc hoàn toàn không hỗ trợ nó.

Bây giờ công việc đã cho tôi bắt đầu vào các dự án yêu cầu VB.net và tôi thấy nó cung cấp cả hai cách về AND và ANDALSO . Cái thứ nhất không bị đoản mạch, và cái thứ hai thì không.

Vì vậy, điều này khiến tôi tự hỏi tại sao? Khi thiết lập nó như thế này dường như ngụ ý rằng nó sẽ xuất hiện khá thường xuyên mà người ta muốn chuyển đổi chế độ. Nhưng tôi không thể nghĩ ra bất kỳ tình huống nào sẽ là điều tồi tệ khi sử dụng Short Circuit .

Tôi biết điều này rất có thể có được nhiều thứ tùy chọn hơn, vì vậy nếu tôi cần đặt nó ở một nơi khác, chỉ cần cho tôi biết nơi.

Mặc dù tôi hy vọng có ít nhất một câu trả lời chính thức, nhưng tại sao có cả hai lựa chọn sẽ tốt hơn sau đó luôn luôn thực hiện Short Circuit , khi nó có sẵn.

Một số thuật ngữ trong một biểu thức logic có thể có tác dụng phụ. Đôi khi cần phải đảm bảo tất cả các tác dụng phụ xảy ra theo thứ tự đã nêu và không có tác dụng nào bị bỏ qua và đó là kết quả đánh giá hướng dẫn logic:

if not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

Trong các trường hợp khác, bạn không muốn đánh giá bất kỳ điều khoản nào còn lại nếu đánh giá trước đó trả về sai.

if IsAirborne() and not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

Một số người sẽ / đã lập luận rằng việc dựa vào hành vi ngắn mạch trong ví dụ thứ hai là hình thức xấu, nhưng đó là đi vào phong cách mã hóa và hệ thống niềm tin. Có rất nhiều đoạn mã rất hay trên thế giới phụ thuộc vào gần như mọi tính năng mà ngôn ngữ cung cấp, và đó chính là cách nó diễn ra.

ANDALSO của VB rất sắc nét và dường như là một nỗ lực để thực hành dễ chấp nhận hơn.

Như JimmyJames chỉ ra trong câu trả lời của mình, có thể có những hàm ý hiệu suất có thể đo lường được xung quanh việc đánh giá ngắn mạch. Các ngôn ngữ không cung cấp cơ chế, luôn đánh giá mọi thuật ngữ của biểu thức, trong khi các ngôn ngữ cung cấp nó, có thể tạo ra các câu lệnh nhánh bổ sung. Dù bằng cách nào, phần lớn phụ thuộc vào số bước xử lý cần thiết để đánh giá từng điều khoản và cũng dựa trên kiến ​​trúc trình biên dịch và CPU. Thông thường bạn sẽ không quan tâm đến những điều như vậy cho đến khi bạn có một nút thắt được đo lường trong mã và cần tìm ra cách làm giảm bớt nó. Bất kỳ quy tắc nào hoặc không liên quan đến việc cho phép đánh giá ngắn mạch trong mã của bạn sẽ có khả năng gây ra mã chậm hơn và tối ưu hóa sớm có thể gây lãng phí toàn bộ thời gian, vì vậy hãy luôn đo lường, sau đó tối ưu hóa.

Rõ ràng, câu hỏi của bạn không phải là về việc ngắn mạch nói chung là tốt hay xấu, mà là về lý do tại sao VB.NET cung cấp các toán tử có và không có nó. Với suy nghĩ này, câu trả lời cho

Khi nào thì đánh giá ngắn mạch xấu?

chỉ đơn giản là: khi nó vi phạm khả năng tương thích ngược .

Ok, bây giờ bạn có thể nói VB.NET không tương thích ngược với VB6 hoặc VBA cũ, tuy nhiên ít nhất một số phần của ngôn ngữ là. Quyết định của Microsoft về việc giữ ngữ nghĩa AND và OR cũ (không bị đoản mạch) đã tạo ra một loại lỗi rất lớn ít xảy ra khi chuyển các chương trình VB cũ sang VB.NET.

Mặt khác, các nhà thiết kế ngôn ngữ VB.NET có thể đã chia sẻ ý kiến ​​của bạn về việc đoản mạch là một điều tốt. Khi tôi nhớ chính xác, các phiên bản tiền phát hành VB.NET đầu tiên cung cấp cho các toán tử AND hoặc OR bị đoản mạch, nhưng phản hồi của nhà phát triển phải rất tệ khi MS rút quyết định này trước khi VB.NET 1.0 xuất hiện. Vì vậy, các nhà thiết kế đã quyết định triển khai nó theo các từ khóa mới ANDALSOvà ORELSEnhư một sự đánh đổi giữa tính tương thích và tính hữu dụng ngược.

IMHO đây là một quyết định tốt. Tôi đã phải chuyển một số chương trình cũ hơn trong thập kỷ qua và không phải phân tích tác động nặng nề cho mọi biểu hiện logic bao gồm AND và / hoặc OR (ý định chơi chữ) khiến cho công việc đó trở nên dễ dàng và kinh tế hơn rất nhiều. Mặt khác, bất cứ khi nào tôi phải viết một biểu thức logic mới trong VB.NET, lựa chọn mặc định của tôi cho các toán tử là các dạng ngắn mạch, đó là những gì tôi đã sử dụng từ C, C ++, C #, v.v. tôi viết một số thành ngữ ở dạng ngắn gọn hơn (ngay cả khi ANDALSO cần thêm 4 ký tự để gõ).

Nếu bạn không bị thuyết phục, tôi khuyên bạn nên đọc bài viết tuyệt vời của Joel Spolsky về Tai nghe sao Hỏa , đó là lý do tại sao các quyết định thiết kế ban đầu trong phát triển phần mềm có thể dễ dàng bị thu hồi sau khi thành phần hoặc ngôn ngữ hoặc API được đặt ở một cơ sở người dùng có kích thước nhất định .

Khi nào đánh giá ngắn tuần hoàn xấu?

Chúng trở nên xấu , ngay khi bạn bắt đầu dựa vào các tác dụng phụ của các biểu thức mà bạn mong đợi sẽ được thực hiện trong việc đánh giá kết quả tổng thể boolean.

Hãy cẩn thận: Đây là một chút bí truyền trong hầu hết các trường hợp, các nhà phát triển không nên lo lắng về nó. Nhưng ... có thể có một cú đánh hiệu suất do đánh giá có điều kiện vì nó tạo ra sự phân nhánh trong thực thi. Một hoạt động không ngắn mạch không phân nhánh và dễ dự đoán hơn.

Lý do điều này hiếm khi quan trọng là chi phí thường nhỏ và cũng thường vượt trội so với chi phí đánh giá điều kiện thứ hai (hoặc thứ ba, v.v.). Điều này sẽ chỉ trở thành vấn đề trong các thói quen đắt tiền tính toán khi cần hiệu suất cao và nó vẫn có thể không còn quan trọng nữa.

Pascal không xác định liệu AND và OR có sử dụng đánh giá ngắn mạch hay không, mang lại cho bạn điều tồi tệ nhất của cả hai thế giới.

C và C ++ có các phép toán bitwise & và | trong thực tế cung cấp cho bạn các hoạt động không ngắn mạch. Và trình biên dịch có thể tự do đánh giá bất kỳ cách nào họ thích nếu nó không tạo ra sự khác biệt có thể quan sát được.