Tại sao là những người khác nếu Elif khác tuyên bố hầu như không bao giờ ở định dạng bảng?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Đưa ra các ví dụ trên, tôi không hiểu tại sao tôi hầu như không bao giờ thấy kiểu đầu tiên trong các cơ sở mã. Đối với tôi, bạn biến mã thành một định dạng bảng hiển thị rõ ràng những gì bạn muốn. Cột đầu tiên hầu như có thể được bỏ qua. Cột thứ hai xác định điều kiện và cột thứ ba cung cấp cho bạn đầu ra bạn muốn. Dường như, ít nhất là với tôi, thẳng thắn và dễ đọc. Tuy nhiên, tôi luôn thấy loại tình huống / trường hợp chuyển đổi đơn giản này xuất hiện ở định dạng thụt lề, mở rộng. Tại sao vậy? Mọi người có tìm thấy định dạng thứ hai dễ đọc hơn không?

Trường hợp duy nhất mà điều này có thể có vấn đề là nếu mã thay đổi và lâu hơn. Trong trường hợp đó, tôi nghĩ việc tái cấu trúc mã thành định dạng dài, thụt lề là hoàn toàn hợp lý. Có phải mọi người đều làm theo cách thứ hai đơn giản vì đó là cách nó luôn được thực hiện? Là người ủng hộ của quỷ, tôi đoán một lý do khác có thể là do mọi người tìm thấy hai định dạng khác nhau tùy thuộc vào mức độ phức tạp của các câu lệnh if / other gây nhầm lẫn? Bất kỳ cái nhìn sâu sắc sẽ được đánh giá cao.

Một lý do có thể là bạn không sử dụng ngôn ngữ phổ biến.

Một vài ví dụ ngược lại:

Haskell với lính canh và với các mẫu:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang với các mẫu:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

Nói chung, tôi thấy định dạng bảng khá phổ biến với các ngôn ngữ chức năng (và trong các biểu thức dựa trên biểu thức chung), trong khi ngắt dòng là phổ biến nhất trong các ngôn ngữ khác (chủ yếu dựa trên câu lệnh).

Nó dễ đọc hơn. Một vài lý do tại sao:

• Gần như mọi ngôn ngữ đều sử dụng cú pháp này (không phải tất cả, hầu hết - ví dụ của bạn dường như là Python)
• isanae đã chỉ ra trong một bình luận rằng hầu hết các trình sửa lỗi đều dựa trên dòng (không dựa trên câu lệnh)
• Nó bắt đầu trông thậm chí còn xấu xí hơn nếu bạn phải dấu chấm phẩy nội tuyến hoặc niềng răng
• Nó đọc từ trên xuống dưới trơn tru hơn
• Nó trông khủng khiếp không thể đọc được nếu bạn có bất cứ điều gì khác ngoài các tuyên bố trở lại tầm thường
  • Bất kỳ cú pháp có ý nghĩa thụt lề nào sẽ bị mất khi bạn đọc lướt mã vì mã điều kiện không còn được phân tách trực quan (từ Dan Neely )
  • Điều này sẽ đặc biệt tệ nếu bạn tiếp tục vá / thêm các mục vào dòng 1 nếu câu lệnh
• Nó chỉ có thể đọc được nếu tất cả các kiểm tra nếu của bạn có cùng độ dài
• Điều đó có nghĩa là bạn không thể định dạng phức tạp nếu các câu lệnh thành các câu lệnh đa dòng, chúng sẽ phải là oneliners
• Tôi có nhiều khả năng nhận thấy lỗi / luồng logic khi đọc từng dòng theo chiều dọc, không cố phân tích nhiều dòng với nhau
• Bộ não của chúng ta đọc hẹp hơn, văn bản cao hơn NHIỀU nhanh hơn văn bản dài, ngang

Giây phút bạn cố gắng thực hiện bất kỳ điều gì trong số này, bạn sẽ kết thúc việc viết lại thành các câu lệnh đa dòng. Có nghĩa là bạn chỉ lãng phí thời gian!

Ngoài ra mọi người chắc chắn sẽ thêm một cái gì đó như:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Nó không thường xuyên làm điều này trước khi bạn quyết định định dạng này tốt hơn nhiều so với thay thế của bạn. Ah, nhưng bạn có thể nội tuyến tất cả trong một dòng! enderland chết ở bên trong .

Hoặc này:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Đó là thực sự, thực sự gây phiền nhiễu. Không ai thích định dạng những thứ như thế này.

Và cuối cùng, bạn sẽ bắt đầu cuộc chiến thần thánh về vấn đề "có bao nhiêu khoảng trống cho các tab". Những gì hiển thị hoàn hảo trên màn hình của bạn dưới dạng định dạng bảng có thể không hiển thị trên màn hình của tôi tùy thuộc vào cài đặt.

Khả năng đọc không nên phụ thuộc vào cài đặt IDE.

Tôi là một người tin tưởng vững chắc vào 'mã được đọc nhiều lần, viết ít - vì vậy khả năng đọc là rất quan trọng.'

Một điều quan trọng giúp tôi khi tôi đọc mã của người khác là tuân theo các mẫu 'bình thường' mà mắt tôi được đào tạo để nhận ra. Tôi có thể đọc biểu mẫu thụt lề một cách dễ dàng nhất vì tôi đã thấy nó rất nhiều lần mà nó đăng ký gần như tự động (với một chút nỗ lực nhận thức từ phía tôi). Không phải vì nó 'đẹp hơn' - bởi vì nó tuân theo các quy ước mà tôi đã từng sử dụng. Nhịp đập 'tốt hơn' ...

Cùng với các nhược điểm khác đã được đề cập, bố cục dạng bảng làm tăng tỷ lệ xung đột kiểm soát phiên bản yêu cầu can thiệp thủ công.

Khi một khối mã được sắp xếp theo bảng cần được sắp xếp lại, hệ thống kiểm soát phiên bản sẽ coi mỗi dòng đó đã được sửa đổi:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Bây giờ giả sử rằng trong thời gian trung bình, ở một nhánh khác, một lập trình viên đã thêm một dòng mới vào khối mã được căn chỉnh:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

Sáp nhập chi nhánh đó sẽ thất bại:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Nếu mã được sửa đổi không được sử dụng căn chỉnh bảng, việc hợp nhất sẽ tự động thành công.

(Câu trả lời này là "đạo văn" từ bài viết của riêng tôi không khuyến khích căn chỉnh bảng trong mã).

Các định dạng bảng có thể rất đẹp nếu mọi thứ luôn vừa với chiều rộng được phân bổ. Tuy nhiên, nếu có thứ gì đó vượt quá chiều rộng được phân bổ, thì thường cần phải có một phần của bảng không được xếp cùng với phần còn lại của bảng hoặc điều chỉnh bố cục của mọi thứ khác trong bảng để khớp với mục dài .

Nếu các tệp nguồn được chỉnh sửa bằng các chương trình được thiết kế để hoạt động với dữ liệu định dạng bảng và có thể xử lý các mục quá dài bằng cách sử dụng cỡ chữ nhỏ hơn, chia chúng thành hai dòng trong cùng một ô, v.v. thì có thể sử dụng bảng định dạng thường xuyên hơn, nhưng hầu hết các trình biên dịch muốn các tệp nguồn không có các loại đánh dấu mà các trình soạn thảo như vậy sẽ cần lưu trữ để duy trì định dạng. Sử dụng các dòng có số lượng thụt lề khác nhau nhưng không có bố cục nào khác không đẹp như định dạng bảng trong trường hợp tốt nhất, nhưng nó không gây ra gần như nhiều vấn đề trong trường hợp xấu nhất.

Có một tuyên bố 'chuyển đổi' cung cấp loại điều này cho các trường hợp đặc biệt, nhưng tôi đoán đó không phải là những gì bạn đang hỏi về.

Tôi đã thấy nếu các câu lệnh ở định dạng bảng, nhưng phải có một số lượng lớn các điều kiện để làm cho nó đáng giá. 3 nếu các câu lệnh được hiển thị tốt nhất ở định dạng truyền thống, nhưng nếu bạn có 20, thì việc hiển thị chúng trong một khối lớn được định dạng để làm cho nó rõ ràng hơn nhiều.

Và có một điểm: sự rõ ràng. Nếu nó làm cho nó dễ nhìn hơn (và ví dụ đầu tiên của bạn không dễ thấy nơi: dấu phân cách) thì hãy định dạng nó cho phù hợp với tình huống. Mặt khác, hãy gắn bó với những gì mọi người mong đợi, vì điều đó luôn dễ nhận ra hơn.

Nếu biểu thức của bạn thực sự dễ dàng thì hầu hết các ngôn ngữ lập trình đều cung cấp toán tử phân nhánh ?:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Đây là một định dạng bảng ngắn có thể đọc được. Nhưng phần quan trọng là: Tôi nhìn thoáng qua hành động "chính" là gì. Đây là một tuyên bố trở lại! Và giá trị được quyết định bởi các điều kiện nhất định.

Mặt khác, nếu bạn có các nhánh thực thi các mã khác nhau, tôi thấy nó dễ đọc hơn rất nhiều để thụt các khối này. Bởi vì bây giờ có các hành động "chính" khác nhau tùy thuộc vào câu lệnh if. Trong một trường hợp chúng tôi ném, trong một trường hợp chúng tôi đăng nhập và trả lại hoặc chỉ trả lại. Có một luồng chương trình khác nhau tùy thuộc vào logic, vì vậy các khối mã đóng gói các nhánh khác nhau và làm cho chúng nổi bật hơn cho nhà phát triển (ví dụ: đọc tốc độ một chức năng để nắm bắt luồng chương trình)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Như enderland đã nói, bạn cho rằng bạn chỉ có một lần "trả lại" là hành động và bạn có thể gắn thẻ "trả lại" đó vào cuối điều kiện. Tôi muốn cung cấp thêm một số chi tiết về lý do tại sao điều này sẽ không thành công.

Tôi không biết ngôn ngữ ưa thích của bạn là gì, nhưng tôi đã mã hóa bằng C trong một thời gian dài. Có một số tiêu chuẩn mã hóa nhằm tránh một số lỗi mã hóa tiêu chuẩn bằng cách không tuân theo các cấu trúc mã dễ bị lỗi, trong mã hóa ban đầu hoặc trong quá trình bảo trì sau này. Tôi quen thuộc nhất với MISRA-C, nhưng có những người khác, và nói chung tất cả họ đều có các quy tắc tương tự vì họ đang giải quyết các vấn đề tương tự trong cùng một ngôn ngữ.

Một lỗi phổ biến mà các tiêu chuẩn mã hóa thường mắc phải là lỗi nhỏ này: -

if (x == 10)
    do_something();
    do_something_else();

Điều này không làm những gì bạn nghĩ nó làm. Theo như C có liên quan, nếu x là 10 thì bạn gọi do_something(), nhưng sau đó do_something_else()được gọi bất kể giá trị của x . Chỉ hành động ngay sau câu lệnh "nếu" là có điều kiện. Đây có thể là những gì các lập trình viên dự định, trong trường hợp đó có một bẫy tiềm năng cho các nhà bảo trì; hoặc nó có thể không phải là những gì lập trình viên dự định, trong trường hợp đó có một lỗi. Đó là một câu hỏi phỏng vấn phổ biến.

Giải pháp trong các tiêu chuẩn mã hóa là bắt buộc niềng răng xung quanh tất cả các hành động có điều kiện, ngay cả khi chúng là dòng đơn. Bây giờ chúng tôi nhận được

if (x == 10)
{
    do_something();
    do_something_else();
}

hoặc là

if (x == 10)
{
    do_something();
}
do_something_else();

và bây giờ nó hoạt động chính xác và rõ ràng cho người bảo trì.

Bạn sẽ nhận thấy rằng điều này hoàn toàn không tương thích với định dạng kiểu bảng của bạn.

Một số ngôn ngữ khác (ví dụ Python) đã xem xét vấn đề này và quyết định rằng vì các lập trình viên đang sử dụng khoảng trắng để làm cho bố cục rõ ràng, nên sử dụng khoảng trắng thay vì dấu ngoặc. Vì vậy, trong Python,

if x == 10:
    do_something()
    do_something_else()

thực hiện các cuộc gọi đến cả hai do_something()và có do_something_else()điều kiện trên x == 10, trong khi đó

if x == 10:
    do_something()
do_something_else()

có nghĩa là chỉ do_something()có điều kiện trên x và do_something_else()luôn được gọi.

Đó là một khái niệm hợp lệ và bạn sẽ tìm thấy một vài ngôn ngữ sử dụng nó. (Lần đầu tiên tôi nhìn thấy nó trong Occam2, trở lại khi.) Một lần nữa, bạn có thể dễ dàng thấy rằng định dạng kiểu bảng của bạn không tương thích với ngôn ngữ.

Bố cục dạng bảng có thể hữu ích trong một số trường hợp giới hạn, nhưng có vài lần nó hữu ích với if.

Trong trường hợp đơn giản ?: Có thể là một lựa chọn tốt hơn. Trong trường hợp trung bình, một công tắc thường phù hợp hơn (nếu ngôn ngữ của bạn có). Trong các trường hợp phức tạp, bạn có thể thấy rằng một bảng gọi phù hợp hơn.

Đã nhiều lần khi tái cấu trúc mã mà tôi đã sắp xếp lại thành dạng bảng để làm cho nó rõ ràng. Rất hiếm khi tôi để nó như vậy trong hầu hết các trường hợp, có một cách tốt hơn để giải quyết vấn đề một khi bạn hiểu nó. Đôi khi, một tiêu chuẩn thực hành hoặc bố cục mã hóa cấm nó, trong trường hợp đó một nhận xét là hữu ích.

Có một số câu hỏi về ?:. Vâng, đó là toán tử ternary (hoặc như tôi muốn nghĩ về nó nếu giá trị). trong lần đầu tiên, ví dụ này hơi phức tạp đối với ?: (và quá lạm dụng? giải pháp.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Tôi không thấy bất cứ điều gì sai với định dạng bảng. Sở thích cá nhân, nhưng tôi sẽ sử dụng một ternary như thế này:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Không cần lặp lại returnmỗi lần :)