2010-06-30 29 views
6

Tôi đang làm việc với Delphi. Liệu nó có tạo ra sự khác biệt về hiệu suất nếu chúng tôi viết if condition theo những cách khác nhau không? Ví dụ:Khối bắt đầu có ảnh hưởng đến hiệu suất của câu lệnh có điều kiện không?

if (condition) then 
    someVar := someVal 
else 
    someVar := someOtherVal; 

Hoặc chúng ta có thể viết:

if (condition) then begin 
    someVar := someVal; 
end else begin 
    someVar := someOtherVal; 
end; 

tôi thích lựa chọn thứ hai chỉ vì nó trông tốt hơn so với người đầu tiên.

+10

"kết thúc khác bắt đầu" được coi là không chính xác theo hướng dẫn kiểu đối tượng pascal. http://edn.embarcadero.com/article/10280#8.2.3 –

+0

Nếu bạn lo lắng về hiệu suất, hãy xem xét điều này: http://stackoverflow.com/questions/2679186/most-hazardous-performance-bottleneck-misconceptions/2679514 # 2679514 –

+9

@Chris: đó là một ví dụ hay về hướng dẫn về phong cách, nhưng không phải là kết thúc tất cả và là tất cả bố cục mã tốt. Có các đối số khả năng đọc tốt để sử dụng kết thúc khác bắt đầu trên một kiểu dòng. Tôi sẽ tìm thấy liên kết nếu bạn quan tâm. Và trong khi tôi biết hướng dẫn về phong cách thực sự sử dụng các thuật ngữ chính xác và không chính xác, nó là một vấn đề hoàn toàn chủ quan mà không bao giờ nên sử dụng những thuật ngữ này ngay từ đầu. –

Trả lời

21

Không, không có sự khác biệt về hiệu suất, mã được tạo sẽ giống nhau.

Một khía cạnh có thể quan trọng hơn lựa chọn thứ hai trông đẹp hơn, là tốt hơn cho việc bảo trì. Nếu bạn cần thêm câu lệnh khác trong khối khác, bạn sẽ không vô tình quên thêm phần bắt đầu và kết thúc, điều này sẽ đưa câu lệnh ra bên ngoài if và luôn được thực thi.

+0

Điểm tốt ... +1 – Himadri

+1

+1 cho mẹo bảo trì. –

+2

Nếu bạn sử dụng thụt đầu dòng thích hợp và biết bạn đang làm gì, làm thế nào bạn có thể "vô tình quên thêm đầu và cuối"? Tôi có thể phát hiện thiếu 'begin's và' end's trong giấc ngủ của tôi! –

3

Điều này sẽ không tạo sự khác biệt về hiệu suất.

beginend cho trình biên dịch biết một khối mã bắt đầu và kết thúc, nhưng không cần tính toán ở đó.

1

Điều duy nhất bạn nên ghi nhớ về if-elseif-else là giữ các trường hợp phổ biến trong mã của bạn trước các trường hợp cạnh, sao cho các điều kiện ít nhất có thể được đánh giá.

+0

Bạn có chắc chắn rằng bạn đã đọc câu hỏi không? –

+0

Có, điều đó có thể hữu ích trong vấn đề hiệu suất ... Không nên nhận -1. – Himadri

+0

Câu trả lời đã được chỉnh sửa. Tôi sẽ loại bỏ -1 của tôi nếu chỉ có máy chủ cho tôi ... –

1

Bắt đầu và kết thúc không làm chậm mã của bạn, như những người khác đã nói. Tôi viết một câu trả lời khác để khuyến khích bạn thậm chí rõ ràng hơn LUÔN LUÔN sử dụng bắt đầu và kết thúc bất cứ khi nào bạn có thể sử dụng chúng.

Thật tốt khi được tự do bằng cách sử dụng Bắt đầu và Kết thúc và đừng lo lắng về việc chúng làm chậm bạn xuống (bởi vì chúng không).

Nếu bạn đi theo một cách khác, và bỏ qua bắt đầu và kết thúc bất cứ nơi nào bạn có thể, bạn sẽ gặp phải một loại rắc rối khác.

Điều này đã xảy ra với tôi rất nhiều. Bạn có thể gặp rắc rối khi bạn chèn một dòng vào một nơi không có câu lệnh bắt đầu và kết thúc tồn tại. Sau đó bạn kết thúc gãi đầu của bạn tự hỏi những gì bạn đã làm đó đã phá vỡ mã của bạn. Bắt đầu ở mọi nơi, ngay cả khi không cần thiết, là quy trình vận hành chuẩn cho rất nhiều trình lập trình Delphi.

+1

Tôi không bao giờ sử dụng 'bắt đầu ... kết thúc 'khi họ không cần thiết. Điều này làm cho mã dễ đọc hơn nhiều. Tôi chưa bao giờ gặp phải một vấn đề với điều này - không có lỗi, không có trầy xước, không có vấn đề gì. Tôi không thể nhìn thấy bất kỳ lý do nào cho một nhà phát triển Delphi có kinh nghiệm không bỏ qua những thứ không cần thiết'begin ... end's. Nếu bạn chỉ thụt lề mã của bạn một cách chính xác, và nhận thức được hiện tượng "lúng túng khác", thì không có gì có thể đi sai. (Tôi đã phát triển ở Delphi từ năm 12 tuổi, vì vậy tôi biết ngôn ngữ bản năng.) –

+3

Tôi có thể thấy ít nhất một lý do tại sao một nhà phát triển Delphi có kinh nghiệm có thể sử dụng bắt đầu không cần thiết ... kết thúc: Anh ấy có thể có đồng nghiệp không có kinh nghiệm. (Và bên cạnh đó: Tôi nghĩ về bản thân mình là khá kinh nghiệm và tôi thực sự sử dụng chúng khá thường xuyên. Có lẽ tôi không phải là kinh nghiệm như tôi nghĩ hoặc có thể tuyên bố của bạn chỉ là sai.) – dummzeuch

+0

Như bất cứ ai có thể nhìn thấy, mọi người không đồng ý, và vấn đề là rất nhỏ, và có ý nghĩa cuối cùng nhỏ. Bạn phải học cách khắc phục vấn đề của sự lúng túng khác khi nó xảy ra, và bạn phải làm những gì bạn nghĩ là tốt nhất, khi bạn viết mã của bạn. Khi bạn làm việc với một nhóm các nhà phát triển, hy vọng tất cả các bạn có thể đi đến một thỏa thuận. –

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