2010-10-15 27 views
6

Tôi hiện cóC# là thiết kế này "đúng"?

 if (!RunCommand(LogonAsAServiceCommand)) 
      return; 

     if (!ServicesRunningOrStart()) 
      return; 

     if (!ServicesStoppedOrHalt()) 
      return; 

     if (!BashCommand(CreateRuntimeBashCommand)) 
      return; 

     if (!ServicesStoppedOrHalt()) 
      return; 

     if (!BashCommand(BootstrapDataBashCommand)) 
      return; 

     if (!ServicesRunningOrStart()) 
      return; 

làm việc này sẽ sạch hơn? nó có an toàn không?

 if (
      (RunCommand(LogonAsAServiceCommand)) 
     && (ServicesRunningOrStart()) 
     && (ServicesStoppedOrHalt()) 
     && (BashCommand(CreateRuntimeBashCommand)) 
     && (ServicesStoppedOrHalt()) 
     && (BashCommand(BootstrapDataBashCommand)) 
     && (ServicesRunningOrStart()) 
     ) 
     { 
       // code after "return statements" here 
     } 
+5

Hoàn toàn giống nhau và một vấn đề về kiểu dáng ngoại trừ kiểu đầu tiên dễ debug hơn (và thiết lập các điểm ngắt). –

+0

Tôi đồng ý với @Kirk Woll, khi được tối ưu hóa, chúng phải giống nhau nếu trình biên dịch/jitter đủ thông minh. – leppie

Trả lời

1

Bạn nên tuân theo mọi thứ dễ đọc hơn và dễ hiểu hơn.

Trừ khi thực tế không hiệu quả.

+0

+1 Điều này tham gia biểu thức "giữ đơn giản"! =) –

3

Mã đầu tiên có phải là một bộ câu lệnh OR không?

if ( 
     (!RunCommand(LogonAsAServiceCommand)) 
    || (!ServicesRunningOrStart()) 
    || (!ServicesStoppedOrHalt()) 
    || (!BashCommand(CreateRuntimeBashCommand)) 
    || (!ServicesStoppedOrHalt()) 
    || (!BashCommand(BootstrapDataBashCommand)) 
    || (!ServicesRunningOrStart()) 
+1

Nếu bạn làm điều đó như là câu lệnh OR, bạn sẽ nhận được hiệu quả của việc quay trở lại ngay sau khi bất kỳ điều kiện nào là đúng, thay vì chờ xem tất cả các điều kiện đó có đúng không. –

+6

Cả hai '&&' và '||' đều bị đoản mạch, do đó không có lợi thế thực sự để thực hiện điều này. – Ani

+0

+1 cho hiệu suất và để điều chỉnh giải pháp thứ hai của OP. – BrunoLM

2

Hoặc là không sao. Tuy nhiên từ một quan điểm phong cách tôi muốn đề nghị rằng vì đây là một loạt các comands bạn có thể sử dụng một List<Action> để giữ chúng và làm cho dữ liệu chức năng điều khiển.

(new Action[] { func1, func2, .... }).ToList().ForEach(a => a()); 

Tất nhiên kể từ khi các chức năng đã có chữ ký bạn có thể phải làm nhiều người ...

một lần nữa đó là một vấn đề phong cách khác nhau ....

+1

Đây là một cách tiếp cận tốt đẹp, nhưng vẫn không phải là rất gỡ lỗi thân thiện. Đặc biệt là khi bạn đang điền vào danh sách với lambda của tất cả các nơi. Phương pháp bình thường nên được ok mặc dù. – leppie

+0

đã đồng ý về nhận xét gỡ lỗi. Tôi rất dữ liệu trong mã của tôi nhưng nó làm cho nó đơn vị kiểm tra thân thiện hơn. Ngoài ra tôi có xu hướng sử dụng đăng nhập nhiều hơn để gỡ lỗi cho phân tích những ngày này –

+0

Loại công cụ này gỡ lỗi tốt hơn nhiều trong vs2010 :) –

4

Khi tôi nhìn vào cách tiếp cận đầu tiên, suy nghĩ đầu tiên của tôi là lý do mã được viết theo cách đó là các hoạt động liên quan có thể có tác dụng phụ. Từ tên của các phương pháp, tôi giả sử họ làm gì? Nếu vậy, tôi chắc chắn sẽ đi với cách tiếp cận đầu tiên và không phải là thứ hai; Tôi nghĩ rằng người đọc mã của bạn sẽ thấy rất khó hiểu khi thấy biểu thức ngắn mạch && đang được sử dụng để thực thi các điều kiện phụ.

Nếu không có tác dụng phụ, sẽ thực hiện; cả hai đều có thể đọc được hoàn toàn. Nếu bạn thấy rằng có một số điều kiện nhiều hơn hoặc các điều kiện tự khác nhau trong các tình huống khác nhau, bạn có thể thử một cái gì đó như:

Func<bool>[] conditions = ... 
if(conditions.Any(condn => condn())) 
{ 
    ... 
} 

tôi sẽ không thực sự đi với một cách tiếp cận như vậy trong trường hợp của bạn, tuy nhiên.

+0

bạn có ý nghĩa gì bởi "tác dụng phụ"? – bevacqua

+0

http://en.wikipedia.org/wiki/Side_effect_(computer_science). Hiệu quả, những gì tôi có ý nghĩa trong trường hợp này là sự lựa chọn ngắn mạch và không ngắn mạch giới thiệu một sự khác biệt quan sát, chức năng trong trạng thái của chương trình. – Ani

+2

+1 Để cung cấp quy tắc tốt cho việc quyết định giữa câu lệnh nào sẽ dễ đọc hơn. Eric Lippert có một bài viết trên SO một nơi nào đó thảo luận về quy tắc này trong bối cảnh của nhà điều hành ternary, nhưng tôi dường như không thể tìm thấy nó. – Brian

-1

Nếu bạn đang sử dụng mã này nhiều lần tôi sẽ đề nghị bạn đặt nó trong một phương pháp riêng biệt như:

public static class HelperClass 
{ 
    public static bool ServicesRunning() 
    { 
    // Your code here... 
    } 
} 

và gọi nó khi cần thiết

public class SomeClass 
{ 
    // Constructors etc... 
    public void SomeMethod() 
    { 
    if(HelperClass.ServicesRunning()) 
    { 
     // Your code here... 
    } 
    } 
} 
+0

huh, tôi rõ ràng đã làm điều đó? – bevacqua

+0

Vâng, nó không hoàn toàn rõ ràng rằng đó là thiết kế của bạn. Nhưng nếu đó là những gì bạn đã làm tôi chỉ có thể nói rằng tôi đồng ý với thiết kế đó. Sử dụng dài &&/|| nếu báo cáo dễ dàng bị lộn xộn (theo ý kiến ​​của tôi). – Mantisen

Các vấn đề liên quan