Tại sao Python pep-8 khuyến nghị mạnh mẽ khoảng trắng trên các tab để thụt lề?

Tôi thấy trên Stack Overflow và PEP 8 rằng khuyến nghị là chỉ sử dụng khoảng trắng để thụt lề trong các chương trình Python. Tôi có thể hiểu sự cần thiết của thụt đầu dòng nhất quán và tôi đã cảm thấy nỗi đau đó.

Có một lý do cơ bản cho không gian được ưa thích? Tôi đã nghĩ rằng các tab dễ dàng hơn để làm việc với.

Câu trả lời đã được đưa ra ngay trong PEP [ed: đoạn văn này đã được chỉnh sửa vào năm 2013 ]. Tôi trích dẫn:

Cách phổ biến nhất để thụt Python là chỉ với khoảng trắng.

Bạn cần lý do cơ bản nào khác?

Nói một cách thẳng thắn: Cũng xem xét phạm vi của PEP như đã nêu trong đoạn đầu tiên:

Tài liệu này đưa ra các quy ước mã hóa cho mã Python bao gồm thư viện chuẩn trong bản phân phối Python chính.

Mục đích là để làm cho tất cả các mã đi trong phân phối python chính thức được định dạng nhất quán (tôi hy vọng chúng ta có thể đồng ý rằng đây là một điều tốt trên toàn cầu).

Vì quyết định giữa không gian và tab cho một lập trình viên riêng lẻ là a) thực sự là vấn đề của sở thích và b) dễ dàng xử lý bằng các phương tiện kỹ thuật (biên tập viên, tập lệnh chuyển đổi, v.v.), nên có một cách rõ ràng để kết thúc tất cả các cuộc thảo luận: chọn một .

Guido là người được chọn. Anh ta thậm chí không phải đưa ra một lý do, nhưng anh ta vẫn làm bằng cách tham khảo dữ liệu thực nghiệm.

Đối với tất cả các mục đích khác, bạn có thể lấy PEP này làm đề xuất hoặc bạn có thể bỏ qua nó - lựa chọn của bạn, hoặc nhóm của bạn hoặc trưởng nhóm của bạn.

Nhưng nếu tôi có thể cho bạn một lời khuyên: đừng mix'em ;-) [ed: Trộn tab và dấu cách không còn là một lựa chọn.]

Chà, có vẻ như mọi người đều thiên vị mạnh mẽ đối với không gian. Tôi sử dụng các tab độc quyền. Tôi biết rất rõ tại sao.

Tab thực sự là một phát minh tuyệt vời, xuất hiện sau không gian. Nó cho phép bạn thụt lề mà không cần đẩy không gian hàng triệu lần hoặc sử dụng tab giả (tạo ra khoảng trắng).

Tôi thực sự không hiểu tại sao mọi người lại kỳ thị việc sử dụng các tab. Nó rất giống với những người già phân biệt đối xử với những người trẻ tuổi hơn vì đã chọn một công nghệ mới hiệu quả hơn và phàn nàn rằng quay số xung hoạt động trên mọi điện thoại , không chỉ trên những thiết bị mới lạ mắt này. "Quay số bằng âm không hoạt động trên mọi điện thoại, đó là lý do tại sao nó sai".

Trình chỉnh sửa của bạn không thể xử lý các tab đúng cách? Vâng, có được một hiện đại biên tập viên . Có thể là thời gian tồi tệ, chúng ta đang ở thế kỷ 21 và thời điểm mà một biên tập viên là một phần mềm phức tạp công nghệ cao đã qua. Chúng tôi hiện có rất nhiều biên tập viên để lựa chọn, tất cả chúng đều hỗ trợ các tab tốt. Ngoài ra, bạn có thể xác định một tab sẽ là bao nhiêu, một điều mà bạn không thể làm với khoảng trắng. Không thể xem các tab? Đó là gì cho một cuộc tranh luận? Chà, bạn cũng không thể nhìn thấy không gian!

Tôi có thể rất táo bạo để đề nghị để có được một biên tập viên tốt hơn? Một trong những công nghệ cao này, đã được phát hành khoảng 10 năm trước, có hiển thị các ký tự vô hình ? (mỉa mai tắt)

Sử dụng không gian gây ra nhiều công việc xóa và định dạng hơn. Đó là lý do tại sao (và tất cả những người khác biết điều này và đồng ý với tôi) sử dụng các tab cho Python.

Trộn các tab và khoảng trắng là không có và không có tranh luận về điều đó. Đó là một mớ hỗn độn và không bao giờ có thể làm việc.

Cá nhân tôi không đồng ý với khoảng trắng trên các tab. Đối với tôi, các tab là một ký tự / cơ chế bố cục tài liệu trong khi các khoảng trắng dành cho nội dung hoặc phân định giữa các lệnh trong trường hợp mã.

Tôi phải đồng ý với ý kiến ​​của Jim rằng các tab không thực sự là vấn đề, đó là con người và cách họ muốn trộn các tab và khoảng trắng.

Điều đó nói rằng, tôi đã buộc bản thân mình sử dụng không gian cho mục đích hội nghị. Tôi coi trọng tính nhất quán hơn sở thích cá nhân.

Lý do cho không gian là các tab là tùy chọn. Dấu cách là mẫu số chung thấp nhất thực tế trong dấu câu.

Mỗi trình soạn thảo văn bản đàng hoàng đều có "tab thay thế bằng dấu cách" và nhiều người sử dụng điều này. Nhưng không phải lúc nào cũng vậy.

Mặc dù một số trình soạn thảo văn bản có thể thay thế một khoảng trắng bằng một tab, nhưng điều này thực sự hiếm.

Dòng dưới cùng . Bạn không thể đi sai với không gian. Bạn có thể đi sai với các tab. Vì vậy, không sử dụng các tab và giảm nguy cơ sai lầm.

Vấn đề với các tab là chúng vô hình và mọi người không bao giờ có thể đồng ý về độ rộng của các tab. Khi bạn trộn các tab và khoảng trắng và bạn đặt các tab ở một cái gì đó không phải là Python (sử dụng các tab trong mỗi 8 khoảng trắng), bạn sẽ thấy mã theo một bố cục khác so với Python nhìn thấy nó. Và bởi vì bố cục xác định các khối, bạn sẽ thấy logic khác nhau. Nó dẫn đến các lỗi tinh vi.

Nếu bạn khăng khăng thách thức PEP 8 và sử dụng các tab - hoặc tệ hơn, trộn các tab và khoảng trắng - ít nhất là luôn chạy python với đối số '-tt', làm cho vết lõm không nhất quán (đôi khi là một tab, đôi khi là khoảng trắng cho cùng một vết lõm mức độ) một lỗi. Ngoài ra, nếu có thể, hãy đặt trình chỉnh sửa của bạn để hiển thị các tab khác nhau. Nhưng thực sự, cách tiếp cận tốt nhất là không sử dụng các tab, thời gian.

Các vấn đề chính với thụt lề xảy ra khi bạn trộn các tab và dấu cách. Rõ ràng điều này không cho bạn biết bạn nên chọn cái nào, nhưng đó là một lý do tốt để giới thiệu nó, ngay cả khi bạn chọn nó bằng cách lật một đồng xu.

Tuy nhiên, IMHO có một vài lý do nhỏ để ưu tiên không gian trên các tab:

• Công cụ khác nhau. Đôi khi mã được hiển thị bên ngoài trình soạn thảo của lập trình viên. Ví dụ. đăng lên một nhóm tin hoặc diễn đàn. Các không gian thường làm tốt hơn các tab ở đây - mọi nơi đều có thể được xử lý, các tab cũng hoạt động, nhưng không phải ngược lại.

• Các lập trình viên thấy nguồn khác nhau. Điều này mang tính chủ quan sâu sắc - đó là lợi ích chính của các tab hoặc là lý do để tránh chúng tùy thuộc vào phía bạn. Về mặt tích cực, các nhà phát triển có thể xem nguồn với thụt đầu dòng ưa thích của họ, vì vậy, nhà phát triển thích thụt lề 2 không gian có thể làm việc với nhà phát triển 8 không gian trên cùng một nguồn và vẫn thấy nó như họ muốn. Nhược điểm là có tác động đến điều này - một số người thích 8 không gian vì nó cung cấp phản hồi rất rõ ràng rằng họ quá sâu - họ có thể thấy mã được kiểm tra bởi người đăng ký 2 liên tục trong trình soạn thảo của họ. Việc mọi nhà phát triển nhìn thấy mã theo cùng một cách dẫn đến độ dài dòng wrt thống nhất hơn và các vấn đề khác cũng vậy.

• Tiếp tục thụt dòng. Đôi khi bạn muốn thụt dòng để chỉ ra nó được mang từ dòng trước. ví dụ.

  def foo():
      x = some_function_with_lots_of_args(foo, bar, baz,
                                          xyzzy, blah)

  Nếu sử dụng các tab, không có cách nào để căn chỉnh điều này cho những người sử dụng các tab khác nhau trong trình chỉnh sửa của họ mà không trộn lẫn các khoảng trắng và tab. Điều này có hiệu quả giết chết lợi ích trên.

Rõ ràng, mặc dù, đây là một vấn đề tôn giáo sâu sắc, mà lập trình đang bị vấy bẩn. Vấn đề quan trọng nhất là chúng ta nên chọn một thứ - ngay cả khi đó không phải là thứ bạn thích. Đôi khi tôi nghĩ rằng lợi thế lớn nhất của việc thụt đầu dòng đáng kể là ít nhất chúng ta không phải loay hoay trong việc đặt nẹp.

Cũng đáng đọc là này bài viết của Jamie Zawinski về vấn đề này.

Lưu ý rằng việc sử dụng các tab gây nhầm lẫn một khía cạnh khác của PEP 8:

Giới hạn tất cả các dòng tối đa 79 ký tự.

Giả sử, giả sử rằng bạn sử dụng chiều rộng tab là 2 và tôi sử dụng chiều rộng tab là 8. Bạn viết tất cả mã của mình để các dòng dài nhất của bạn đạt 79 ký tự, sau đó tôi bắt đầu làm việc với tệp của mình. Bây giờ tôi đã có mã khó đọc vì (như các trạng thái PEP):

Gói mặc định trong hầu hết các công cụ phá vỡ cấu trúc trực quan của mã

Nếu tất cả chúng ta sử dụng 4 không gian, thì LUÔN LUÔN giống nhau. Bất cứ ai có trình soạn thảo có thể hỗ trợ độ rộng 80 ký tự đều có thể thoải mái đọc mã. Lưu ý: Giới hạn 80 ký tự là một cuộc chiến thần thánh, vì vậy, đừng bắt đầu ở đây.

Bất kỳ trình soạn thảo không sucky nào cũng nên có tùy chọn sử dụng khoảng trắng như thể chúng là các tab (cả chèn và xóa), vì vậy đó thực sự không nên là một đối số hợp lệ.

Câu trả lời cho câu hỏi là: PEP-8 muốn đưa ra khuyến nghị và đã quyết định rằng vì các không gian phổ biến hơn nên nó sẽ khuyến nghị mạnh mẽ các không gian trên các tab.

Ghi chú về PEP-8

PEP-8 nói 'Sử dụng 4 khoảng trống cho mỗi cấp độ thụt đầu dòng.'
Rõ ràng rằng đây là khuyến nghị tiêu chuẩn.

'Đối với mã thực sự cũ mà bạn không muốn làm hỏng, bạn có thể tiếp tục sử dụng các tab 8 không gian.'
Rõ ràng là có MỘT SỐ trường hợp khi các tab có thể được sử dụng.

'Không bao giờ trộn các tab và dấu cách.'
Đây là một sự cấm đoán rõ ràng về sự pha trộn - tôi nghĩ tất cả chúng ta đều đồng ý về điều này. Python có thể phát hiện ra điều này và thường bị nghẹt thở. Sử dụng đối số -tt làm cho lỗi này rõ ràng.

'Cách phổ biến nhất để thụt Python là chỉ với khoảng trắng. Cách phổ biến thứ hai là chỉ với các tab. '
Điều này nói rõ rằng cả hai đều được sử dụng. Chỉ cần cực kỳ rõ ràng: Bạn vẫn không bao giờ nên trộn các khoảng trắng và tab trong cùng một tệp.

'Đối với các dự án mới, chỉ dành cho không gian được khuyến nghị mạnh mẽ trên các tab.'
Đây là một khuyến nghị rõ ràng và mạnh mẽ, nhưng không cấm các tab.

Tôi không thể tìm thấy câu trả lời hay cho câu hỏi của mình trong PEP-8. Tôi sử dụng các tab mà tôi đã sử dụng trong các ngôn ngữ khác. Python chấp nhận nguồn với việc sử dụng độc quyền các tab. Nó đủ tốt cho tôi.

Tôi nghĩ rằng tôi sẽ phải làm việc với không gian. Trong trình chỉnh sửa của mình, tôi đã cấu hình một loại tệp để sử dụng riêng các khoảng trắng và do đó, nó sẽ chèn 4 khoảng trắng nếu tôi nhấn tab. Nếu tôi nhấn tab quá nhiều lần, tôi phải xóa khoảng trắng! Arrgh! Số lần xóa gấp bốn lần so với các tab! Trình chỉnh sửa của tôi không thể nói rằng tôi đang sử dụng 4 khoảng trắng cho thụt lề (mặc dù trình soạn thảo AN có thể thực hiện được điều này) và rõ ràng khăng khăng xóa từng khoảng trống một lần.

Python không thể được coi là coi các tab là n khoảng trắng khi đọc thụt lề của nó? Nếu chúng ta có thể đồng ý về 4 khoảng trắng trên mỗi lần thụt lề và 4 khoảng trống trên mỗi tab và cho phép Python chấp nhận điều này, thì sẽ không có vấn đề gì.
Chúng ta nên tìm giải pháp thắng-thắng cho các vấn đề.

Tôi đã luôn sử dụng các tab trong mã của mình. Điều đó nói rằng, gần đây tôi đã tìm thấy một lý do để sử dụng khoảng trắng: Khi phát triển trên máy tính bảng internet Nokia N900 của tôi, bây giờ tôi có một bàn phím không có phím tab. Điều này buộc tôi phải sao chép và dán các tab hoặc viết lại mã của mình bằng dấu cách. Tôi đã gặp vấn đề tương tự với các điện thoại khác. Cấp, đây không phải là một cách sử dụng Python tiêu chuẩn, nhưng cần lưu ý.

JWZ nói điều đó tốt nhất :

Khi [mọi người] đọc mã và khi họ viết xong mã mới, họ quan tâm đến việc có bao nhiêu cột màn hình mà mã có xu hướng thụt vào khi một phạm vi mới (hoặc sexpr, hoặc bất cứ điều gì) mở ra ...

... Ý kiến ​​của tôi là cách tốt nhất để giải quyết các vấn đề kỹ thuật là bắt buộc ký tự TAB của ASCII # 9 không bao giờ xuất hiện trong các tệp đĩa: lập trình trình soạn thảo của bạn để mở rộng TAB đến một số khoảng trống thích hợp trước khi ghi các dòng vào đĩa. ..

... Điều này giả định rằng bạn không bao giờ sử dụng các tab ở những nơi chúng thực sự quan trọng, như trong hằng chuỗi hoặc ký tự, nhưng tôi không bao giờ làm điều đó: khi vấn đề là tab, thay vào đó tôi luôn sử dụng '\ t'.

Vì python dựa vào thụt đầu dòng để nhận ra cấu trúc chương trình, nên cần có một cách rõ ràng để xác định danh tính. Đây là lý do để chọn khoảng trắng hoặc tab.

Tuy nhiên, trăn cũng có một triết lý mạnh mẽ là chỉ có một cách để làm mọi việc, do đó cần có một khuyến nghị chính thức cho một cách để thụt đầu dòng.

Cả không gian và tab đều đặt ra những thách thức duy nhất cho một trình soạn thảo để xử lý như thụt lề. Bản thân việc xử lý các tab không thống nhất giữa các biên tập viên hoặc thậm chí là cài đặt người dùng. Vì các không gian không thể định cấu hình, chúng đặt ra lựa chọn hợp lý hơn vì chúng đảm bảo rằng kết quả sẽ trông giống nhau ở mọi nơi.

Lợi thế đáng kể nhất mà tôi có thể nói về các khoảng trắng trên các tab là rất nhiều lập trình viên và dự án sử dụng một số cột được đặt cho mã nguồn và nếu ai đó thực hiện thay đổi với tabstop được đặt thành 2 khoảng trắng và dự án sử dụng 4 khoảng trắng tabstop các dòng dài sẽ quá dài cho cửa sổ soạn thảo của người khác. Tôi đồng ý rằng các tab dễ làm việc hơn nhưng tôi nghĩ các không gian dễ cộng tác hơn, điều này rất quan trọng đối với một dự án nguồn mở lớn như Python.

Bạn có thể có bánh của bạn và ăn nó. Đặt trình chỉnh sửa của bạn để mở rộng các tab vào không gian tự động.

(Điều đó sẽ có :set expandtabtrong Vim.)

Tôi đoán là hầu hết các trình soạn thảo văn bản linux làm cho mặc định trông lớn một cách lố bịch theo mặc định. Tôi không thể nghĩ ra bất kỳ lý do chính đáng nào khác để sử dụng khoảng trắng trên các tab.

Bên cạnh tất cả các lý do khác đã được đặt tên (tính nhất quán, không bao giờ trộn lẫn các khoảng trắng và tab, v.v.) Tôi tin rằng có một vài lý do nữa để quy ước 4 không gian cần lưu ý. Những điều này chỉ áp dụng cho Python (và có thể các ngôn ngữ khác nơi thụt lề có ý nghĩa). Các tab có thể đẹp hơn trong các ngôn ngữ khác, tùy thuộc vào sở thích cá nhân.

1. Nếu một trình soạn thảo không hiển thị các tab (xảy ra, tùy thuộc vào cấu hình, trong một số ít), một tác giả khác có thể cho rằng mã của bạn sử dụng 4 khoảng trắng, hầu như tất cả các mã Python đều có sẵn công khai; nếu cùng một biên tập viên có chiều rộng tab là 4, điều khó chịu có thể xảy ra - ít nhất, người nghèo đó sẽ mất thời gian vì vấn đề thụt lề rất dễ tránh bằng cách tuân thủ quy ước. Vì vậy, đối với tôi, lý do số một là để tránh các lỗi có tính nhất quán.

2. Tái cấu trúc câu hỏi cái nào tốt hơn, các tab hoặc khoảng trắng, người ta nên hỏi những lợi thế của các tab là gì; Tôi đã thấy nhiều bài viết ca ngợi các tab, nhưng một vài lập luận hấp dẫn cho chúng; các biên tập viên giỏi như emacs, vi (m), kate, ... thực hiện thụt lề thích hợp tùy thuộc vào ngữ nghĩa của mã của bạn - ngay cả khi không có tab; các trình soạn thảo tương tự có thể dễ dàng được cấu hình để không bị chặn trên backspace, v.v.

3. Một số người có sở thích rất mạnh mẽ khi nói đến sự tự do của họ trong việc quyết định giao diện / bố cục mã; những người khác coi trọng sự nhất quán đối với sự tự do này. Python làm giảm đáng kể sự tự do này bằng cách ra lệnh rằng thụt đầu dòng được sử dụng cho các khối, v.v ... Điều này có thể được coi là một lỗi hoặc một tính năng, nhưng nó đi kèm với việc chọn Python. Cá nhân, tôi thích tính nhất quán này - khi bắt đầu viết mã cho một dự án mới, ít nhất là bố cục gần với những gì tôi đã từng sử dụng, vì vậy nó khá dễ đọc. Gần như luôn luôn.

4. Sử dụng khoảng trắng để thụt lề cho phép "thủ thuật bố cục" có thể tạo điều kiện để hiểu mã; một số ví dụ trong số này được liệt kê trong PEP8; ví dụ.

   foo = long_function_name(var_one, var_two,
                            var_three, var_four)
   
   # the same for lists
   a_long_list = [1,
                  2,
                  # ...
                  79]
   
   # or dictionaries
   a_dict = {"a_key": "a_value",
             "another_key": "another_value"}

   Tất nhiên, ở trên cũng có thể được viết độc đáo như

   foo = long_function_name(
       var_one, var_two,
       var_three, var_four)
   
   # the same for lists
   a_long_list = [
       1,
       2,
       # ...
       79]
   
   # or dictionaries
   a_dict = {
       "a_key": "a_value",
       "another_key": "another_value"}

   Tuy nhiên, cái sau cần nhiều dòng mã hơn và đôi khi ít dòng hơn được cho là tốt hơn (b / c bạn nhận được nhiều hơn trên một màn hình). Nhưng nếu bạn thích căn chỉnh, các không gian (tốt nhất là được hỗ trợ bởi một trình soạn thảo tốt) sẽ mang lại cho bạn, theo một nghĩa nào đó, tự do hơn trong Python so với các tab. [Chà, tôi đoán một số biên tập viên cho phép bạn thực hiện cùng một w / tab;) - nhưng với khoảng trắng, tất cả chúng đều làm ...]

5. Quay trở lại cùng một lập luận mà mọi người khác đưa ra - PEP 8 ra lệnh (ok, khuyến nghị mạnh mẽ) khoảng trắng. Nếu đến với một dự án chỉ sử dụng các tab, tất nhiên, bạn có ít sự lựa chọn. Nhưng do việc thành lập các công ước PEP 8, gần như tất cả các lập trình viên Python đều quen với phong cách này. Điều này làm cho nó dễ dàng hơn nhiều để tìm thấy sự đồng thuận về một phong cách được hầu hết các lập trình viên chấp nhận ... và việc các cá nhân đồng ý về phong cách có thể rất khó khăn.

6. Các công cụ giúp thực thi kiểu thường nhận thức được PEP 8 mà không cần nỗ lực thêm. Đó không phải là một lý do tuyệt vời, nhưng thật tuyệt khi mọi thứ hoạt động ~ ra khỏi hộp.

Vấn đề phổ biến với các tab là chúng có thể được biểu diễn khác nhau trong các môi trường khác nhau.
Trong một trình soạn thảo nhất định, một tab có thể là 8 dấu cách hoặc có thể là 2.
Trong một số trình chỉnh sửa, bạn có thể kiểm soát điều này, trong khi ở các trình chỉnh sửa khác thì bạn không thể.

Một vấn đề khác với các tab là cách chúng được thể hiện trong đầu ra được in. Tôi tin rằng hầu hết các máy in diễn giải một tab là 8 khoảng trắng.

Với không gian, không có nghi ngờ. Mọi thứ sẽ xếp hàng như tác giả dự định.

Về cuộc thảo luận giữa Jim và Thomas Wouters trong các bình luận.

Vấn đề là ... vì cả chiều rộng của tab và khoảng trắng đều có thể khác nhau - và vì các lập trình viên không thể đồng ý về chiều rộng - tại sao các tab đó lại bị đổ lỗi.

Tôi đồng ý với Jim về điều đó - các tab KHÔNG phải là xấu xa trong chính chúng. Nhưng có một vấn đề...

Với không gian, tôi có thể kiểm soát "MÃ RIÊNG CỦA TÔI" trông như thế nào trong MỌI trình soạn thảo trên thế giới. Nếu tôi sử dụng 4 khoảng trắng - thì cho dù bạn có mở trình soạn thảo nào đi chăng nữa, nó sẽ có cùng khoảng cách với lề trái. Với các tab, tôi rất hài lòng với cài đặt độ rộng tab cho trình chỉnh sửa - ngay cả đối với MÃ SỐ RIÊNG CỦA TÔI. Và tôi không thích điều đó.

Vì vậy, trong khi sự thật là ngay cả các không gian cũng không thể đảm bảo tính nhất quán - ít nhất là chúng đủ khả năng cho bạn kiểm soát nhiều hơn đối với giao diện mã OWN của bạn ở mọi nơi - điều mà các tab không thể.

Tôi nghĩ rằng đó không phải là sự nhất quán trong việc lập trình viên viết mã - mà là sự nhất quán trong các trình soạn thảo hiển thị mã đó - rằng các khoảng trắng giúp dễ dàng đạt được (và áp đặt).