Hướng dẫn can i use tab in python? - tôi có thể sử dụng tab trong python không?

Tôi thấy trên Stack Overflow và Pep 8 rằng khuyến nghị là chỉ sử dụng không gian để thụt vào trong các chương trình Python. Tôi có thể hiểu sự cần thiết phải thụt đầu vào và tôi đã cảm thấy nỗi đau đó.

Có một lý do cơ bản để không gian được ưu tiên? Tôi đã nghĩ rằng các tab dễ làm việc hơn nhiều.

Tylerh

21.2K59 Huy hiệu vàng74 Huy hiệu bạc93 Huy hiệu đồng59 gold badges74 silver badges93 bronze badges

Đã hỏi ngày 23 tháng 9 năm 2008 lúc 13:20Sep 23, 2008 at 13:20

18

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õ lý do tại sao.

Các tab thực sự là một phát minh tuyệt vời, đến sau không gian. Nó cho phép bạn thụt vào mà không cần đẩy không gian hàng triệu lần hoặc sử dụng một tab giả (tạo ra không gian).after spaces. It allows you to indent without pushing space millions of times or using a fake tab (that produces spaces).

Tôi thực sự không hiểu tại sao mọi người đều phân biệt đối xử việc sử dụng các tab. Nó rất giống với những người già phân biệt người trẻ hơn khi chọn một công nghệ mới hơn 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 cái mới lạ mắt này. "Quay số âm không hoạt động trên mọi điện thoại, đó là lý do tại sao nó sai".every phone, not just on these fancy new ones. "Tone dialing doesn't work on every phone, that's why it is wrong".

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 biên tập viên hiện đại. Có thể là thời gian tồi tệ, bây giờ chúng ta đang ở thế kỷ 21 và thời điể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. Bây giờ chúng tôi có hàng tấn và hàng tấn 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 bao nhiêu tab nên là một tab, một điều mà bạn không thể làm với không gian. Không thể nhìn thấy các tab? Đó là gì cho một cuộc tranh luận? Vâng, bạn không thể nhìn thấy không gian cả!modern editor. Might be darn time, we are now in the 21st century and the time when an editor was a high tech complicated piece of software is long past. We have now tons and tons of editors to choose from, all of them that support tabs just fine. Also, you can define how much a tab should be, a thing that you cannot do with spaces. Cannot see tabs? What is that for an argument? Well, you cannot see spaces neither!

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

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à không gian 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.

Nayuki

17.4K5 Huy hiệu vàng52 Huy hiệu bạc77 Huy hiệu đồng5 gold badges52 silver badges77 bronze badges

Đã trả lời ngày 19 tháng 2 năm 2011 lúc 0:56Feb 19, 2011 at 0:56

nigratruonigratruonigratruo

1.9211 Huy hiệu vàng11 Huy hiệu bạc2 Huy hiệu đồng1 gold badge11 silver badges2 bronze badges

9

Câu trả lời đã được đưa ra ngay tại 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 của Python chỉ với không gian.most popular way of indenting Python is with spaces only.

Những lý do cơ bản khác mà bạn cần?

Nói một cách thẳng thắn hơ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 tiêu chuẩn trong phân phối Python chính.

Mục đích là để thực hiện tất cả các mã trong phân phối Python chính thức được định dạng một cách 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 đẹp ™).

Vì quyết định giữa không gian và tab cho một lập trình viên cá nhân là a) thực sự là vấn đề của hương vị 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.) .

Guido là người lựa 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 đề cập đến 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 như một khuyến nghị hoặc bạn có thể bỏ qua nó - sự lựa chọn của bạn hoặc nhóm của bạn hoặc các nhà lãnh đạo nhóm của bạn.

Nhưng nếu tôi có thể cho bạn một lời khuyên: Đừng trộn lẫn ;-) [Ed: Trộn các tab và không gian không còn là một lựa chọn nữa.]

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 15:19Sep 23, 2008 at 15:19

13

Cá nhân tôi không đồng ý với không gian qua 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 nhận xét 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à không gian.

Điều đó nói rằng, tôi đã buộc bản thân phải sử dụng không gian vì lợi ích của quy ước. Tôi đánh giá cao tính nhất quán so với sở thích cá nhân.

Chỉnh sửa 2022: Sử dụng không gian. Thực hiện theo các quy ước ngôn ngữ và những quy ước trong dự án cụ thể mà bạn đang làm. Sử dụng một linter để đảm bảo những quy ước đó được duy trì. Định dạng khi lưu. Lint về cam kết. Điều này sẽ làm giảm "bikeshing" trong một đội. Như tôi đã đề cập rất nhiều năm trước, tính nhất quán đối với sở thích cá nhân! Use spaces. Follow the language conventions and those set in the particular project you're working on. Use a linter to ensure those conventions are maintained. Format on save. Lint on commit. This will reduce "bikeshedding" on a team. As I mentioned so many years ago, consistency over personal preference!

Bikeshing, còn được gọi là Luật tầm thường của Parkinson, mô tả xu hướng của chúng tôi là dành một lượng thời gian không cân xứng cho các vấn đề tầm thường và tầm thường trong khi để lại những vấn đề quan trọng không được giám sát.

Đã trả lời ngày 16 tháng 5 năm 2009 lúc 17:41May 16, 2009 at 17:41

SoviutsoviutSoviut

85.5K46 Huy hiệu vàng180 Huy hiệu bạc246 Huy hiệu Đồng46 gold badges180 silver badges246 bronze badges

19

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

Mỗi trình soạn thảo văn bản tốt có một "tab thay thế bằng khoảng trống" 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 chỉnh sửa văn bản có thể thay thế một không gian bằng một tab, điều này thực sự rất hiếm.

Điểm mấu chốt. Bạn không thể sai với không gian. Bạn có thể sai với các tab. Vì vậy, đừng sử dụng các tab và giảm nguy cơ sai lầm.. You can't go wrong with spaces. You might go wrong with tabs. So don't use tabs and reduce the risk of mistakes.

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 14:45Sep 23, 2008 at 14:45

S.LottS.LottS.Lott

377K79 Huy hiệu vàng503 Huy hiệu bạc773 Huy hiệu Đồng79 gold badges503 silver badges773 bronze badges

4

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ề chiều rộng của các tab. Khi bạn trộn các tab và không gian, và bạn đặt các tabstops ở một thứ khác ngoài Python (sử dụng các tabstops mỗi 8 không gian), bạn sẽ thấy mã trong một bố cục khác 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 tế.

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à không gian-ít nhất luôn luôn chạy Python với đối số '-TT', điều này tạo ra vết lõm không nhất quán (đôi khi là một tab, đôi khi là một không gian cho cùng một thụt lề cấp độ) 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 không phải là sử dụng các tab, giai đoạn.

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 13:24Sep 23, 2008 at 13:24

Thomas Woutersthomas WoutersThomas Wouters

127K23 Huy hiệu vàng146 Huy hiệu bạc122 Huy hiệu Đồng23 gold badges146 silver badges122 bronze badges

26

Các vấn đề chính với thụt lề xảy ra khi bạn trộn các tab và không gian. 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 chính đáng để giới thiệu một, 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ỏ để ủng hộ các không gian qua các tab:

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

• Các lập trình viên thấy nguồn khác nhau. Điều này là chủ quan sâu sắc - đó là lợi ích chính của các tab hoặc một lý do để tránh chúng tùy thuộc vào phía nào bạn đang ở. Về mặt tích cực, các nhà phát triển có thể xem nguồn với thụt đầu tư ưa thích của họ, do đó, nhà phát triển thích thụt 2 không gian có thể hoạt động 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ó những hậu quả đối với điều này - một số người như 8 không gian vì nó đưa ra phản hồi rất rõ ràng rằng họ quá nhiều lồng nhau - họ có thể thấy mã được kiểm tra bởi 2 người đồng hóa liên tục gói trong trình soạn thảo của họ. Có mọi nhà phát triển nhìn thấy mã giống như cách dẫn đến độ dài dòng WRT nhất quán hơn và các vấn đề khác.

• Tiếp tục thụt dòng. Đôi khi bạn muốn thụt vào một dòng để cho biết nó được mang từ cái 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 để sắp xếp điều này cho những người sử dụng các tabstop khác nhau trong trình chỉnh sửa của họ mà không trộn lẫn không gian và tab. Điều này 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 bị ảnh hưởng. Vấn đề quan trọng nhất là chúng ta nên chọn một - ngay cả khi đó không phải là vấn đề bạn ủng hộ. Đôi khi tôi nghĩ rằng lợi thế lớn nhất của thụt lề đáng kể là ít nhất chúng ta sẽ tha thứ cho ngọn lửa vị trí nẹp.

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

Đã trả lời ngày 27 tháng 9 năm 2008 lúc 17:32Sep 27, 2008 at 17:32

BrianbrianBrian

Huy hiệu vàng 115K2828 gold badges107 silver badges111 bronze badges

8

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

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

Theo giả thuyết, 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 trên tệp của mình. Bây giờ tôi đã có mã khó đọc bởi vì (như PEP tuyên bố):

Bao bọc 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, nó luôn giống nhau. Bất cứ ai có biên tập viên có thể hỗ trợ chiều rộng 80 ký tự đều có thể thoải mái đọc mã. Lưu ý: Giới hạn 80 nhân vật là một cuộc chiến thánh trong chính nó, vì vậy chúng ta đừng bắt đầu điều đó ở đây.

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

Đã trả lời ngày 3 tháng 8 năm 2013 lúc 15:49Aug 3, 2013 at 15:49

Thane Brimhallthane BrimhallThane Brimhall

9.0175 Huy hiệu vàng34 Huy hiệu bạc49 Huy hiệu đồng5 gold badges34 silver badges49 bronze badges

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ì không gian phổ biến hơn nên nó sẽ đề xuất mạnh mẽ các không gian qua các tab.

Ghi chú trên PEP-8

PEP-8 cho biết 'Sử dụng 4 không gian trên mỗi cấp độ thụt.' Rõ ràng rằng đây là khuyến nghị tiêu chuẩn.
Its clear that this is the standard recommendation.

'Đối với mã thực sự cũ mà bạn không muốn gây rối, 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.
Its clear that there are SOME circumstances when tabs can be used.

'Không bao giờ trộn các tab và không gian.' Đây là một sự cấm đoán rõ ràng của sự pha trộn - Tôi nghĩ rằng tất cả chúng ta đều đồng ý về điều này. Python có thể phát hiện điều này và thường nghẹt thở. Sử dụng đối số -TT làm cho đây là một lỗi rõ ràng.
This is a clear prohibition of mixing - I think we all agree on this. Python can detect this and often chokes. Using the -tt argument makes this an explicit error.

'Cách phổ biến nhất để thụt lề trăn chỉ với không gian. Cách phổ biến thứ hai chỉ với các tab. ' Điều này rõ ràng nói rằng cả hai đều được sử dụng. Chỉ để cực kỳ rõ ràng: bạn vẫn không bao giờ trộn các khoảng trống và tab trong cùng một tệp.
This clearly states that both are used. Just to be ultra-clear: You should still never mix spaces and tabs in same file.

'Đối với các dự án mới, chỉ dành cho không gian được khuyến nghị mạnh mẽ qua các tab.' Đây là một khuyến nghị rõ ràng, và là một đề xuất mạnh mẽ, nhưng không phải là sự cấm đoán của các tab.
This is a clear recommendation, and a strong one, but not a prohibition of tabs.

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

Tôi nghĩ rằng tôi sẽ đi làm với không gian. Trong trình soạn thảo của mình, tôi đã cấu hình một loại tệp để sử dụng các khoảng trống và do đó nó 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 không gian! ARRGH! Bốn lần số lần xóa như 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 các bên (mặc dù một biên tập viên có thể làm điều này) và rõ ràng là khăng khăng xóa từng khoảng trống.Arrgh! Four times as many deletes as tabs! My editor can't tell that I'm using 4 spaces for indents (although AN editor might be able to do this) and obviously insists on deleting the spaces one at a time.

Không thể được yêu cầu Python coi các tab là N không gian khi các vết lõm đọc của nó? Nếu chúng ta có thể đồng ý về 4 không gian trên mỗi thụt lề và 4 không gian 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 các giải pháp thắng-thắng cho các vấn đề.
We should find win-win solutions to problems.

Đã trả lời ngày 27 tháng 9 năm 2008 lúc 16:56Sep 27, 2008 at 16:56

Quamranaquaranaquamrana

36K12 Huy hiệu vàng55 Huy hiệu bạc68 Huy hiệu Đồng12 gold badges55 silver badges68 bronze badges

4

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 không gian: khi phát triển trên máy tính bảng Internet Nokia N900 của mình, giờ tôi đã có một bàn phím không có khóa 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 tôi bằng khoảng trắng. Tôi đã gặp phải 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 tiêu chuẩn của Python, nhưng một cái gì đó cần lưu ý.

Đã trả lời ngày 5 tháng 1 năm 2012 lúc 18:31Jan 5, 2012 at 18:31

SkylerskylerSkyler

8991 Huy hiệu vàng9 Huy hiệu bạc24 Huy hiệu đồng1 gold badge9 silver badges24 bronze badges

1

Vì Python phụ thuộc vào thụt lề để nhận ra cấu trúc chương trình, một cách rõ ràng để xác định nhận dạng là bắt buộc. Đây là lý do để chọn không gian hoặc tab.

Tuy nhiên, Python cũng có một triết lý mạnh mẽ 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ực hiện thụt lề.

Cả hai không gian và tab đều đặt ra những thách thức độc đáo cho một biên tập viên để xử lý như thụt lề. Việc tự xử lý các tab không đồng nhất giữa các trình chỉnh sửa hoặc thậm chí cài đặt người dùng. Vì không gian không có 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 ở khắp mọi nơi giống nhau.

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 13:35Sep 23, 2008 at 13:35

Florian Böschflorian BöschFlorian Bösch

27.1k11 Huy hiệu vàng48 Huy hiệu bạc53 Huy hiệu Đồng11 gold badges48 silver badges53 bronze badges

3

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 số lượng cột màn hình mà mã có xu hướng thụt vào khi 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 ASCII #9 không bao giờ xuất hiện trong các tệp đĩa: lập trình trình chỉnh sửa của bạn để mở rộng các tab sang số lượng không gian thích hợp trước khi viết 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ự có ý nghĩa, như trong các hằng số chuỗi hoặc ký tự, nhưng tôi không bao giờ làm điều đó: khi nó là một tab, tôi luôn sử dụng '\ t' thay vào đó.

Đã trả lời ngày 27 tháng 9 năm 2008 lúc 17:50Sep 27, 2008 at 17:50

Mark Cidademark CidadeMark Cidade

97.1K31 Huy hiệu vàng222 Huy hiệu bạc234 Huy hiệu Đồng31 gold badges222 silver badges234 bronze badges

4

Ưu điểm quan trọng nhất mà tôi có thể nói về các không gian so với các tab là rất nhiều lập trình viên và dự án sử dụng số lượng cột đặt cho mã nguồn và nếu ai đó thực hiện thay đổi với tabstop của họ được đặt thành 2 khoảng trắng và dự án Tabstop Các dòng dài sẽ quá dài đối với cửa sổ biên tập viên 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ĩ rằng không gian dễ dàng hơn cho sự hợp tác, điều này rất quan trọng trên một dự án nguồn mở lớn như Python.

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 13:30Sep 23, 2008 at 13:30

Sirwartsirwartsirwart

2.3742 Huy hiệu vàng14 Huy hiệu bạc7 Huy hiệu đồng2 gold badges14 silver badges7 bronze badges

1

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 để tự động mở rộng các tab thành không gian.

(Đó sẽ là :set expandtab trong vim.)

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 13:52Sep 23, 2008 at 13:52

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 các không gian và tab, v.v.) Tôi tin rằng có thêm một vài lý do cho quy ước 4 không gian lưu ý. Chúng chỉ áp dụng cho Python (và có thể các ngôn ngữ khác có ý nghĩa thụt lề). 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 (điều này xảy ra, tùy thuộc vào cấu hình, trong một số khá nhiều), 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, b/c Hầu hết tất cả mã python đều được công khai; Nếu cùng một biên tập viên có chiều rộng tab là 4, những điều khó chịu có thể xảy ra - ít nhất, người nghèo đó sẽ mất thời gian trong một vấn đề thụt lề sẽ 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 lỗi với tính nhất quán.

2. Tái cấu trúc câu hỏi đó là tốt hơn, các tab hoặc không gian, người ta nên hỏi những lợi thế của 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 đối số hấp dẫn cho chúng; Các biên tập viên tốt 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 chỉnh sửa tương tự có thể dễ dàng được cấu hình để không được công việc 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 của mã; Những người khác đánh giá cao sự nhất quán so với tự do này. Python làm giảm đáng kể sự tự do này bằng cách chỉ ra rằng thụt lề đượ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 mã hóa một dự án mới, ít nhất là bố cục gần với những gì tôi đã quen, vì vậy nó khá dễ đọc. Gần như luôn luôn.

4. Sử dụng không gian để thụt lề cho phép "các thủ thuật bố trí" 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, những điều trên cũng có thể được viết độc đáo là

   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, phần sau có nhiều dòng mã hơn và đôi khi các dòng ít hơn được lập luận là tốt hơn (b/c bạ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, không gian (tốt nhất là được hỗ trợ bởi một biên tập viên tốt) cho bạn, theo một nghĩa nào đó, tự do hơn trong Python hơn 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 không gian, tất cả đều làm ...]

5. Quay trở lại với cùng một lập luận mà mọi người khác đưa ra - PEP 8 ra lệnh (OK, rất khuyến khích) không gian. Tất nhiên, nếu đến một dự án chỉ sử dụng các tab, bạn có rất ít sự lựa chọn. Nhưng vì việc thành lập các quy ước PEP 8, hầu hết 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ó rất 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 phong cách 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 có mọi thứ hoạt động ~ ra khỏi hộp.

Đã trả lời ngày 25 tháng 2 năm 2013 lúc 21:11Feb 25, 2013 at 21:11

Tôi đoán là hầu hết các trình chỉnh sửa 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.

Đã trả lời ngày 26 tháng 2 năm 2019 lúc 0:27Feb 26, 2019 at 0:27

Vấn đề phổ quát với các tab là chúng có thể được thể hiện khác nhau trong 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 khoảng trống hoặc có thể là 2. Trong một số trình soạn thảo, bạn có thể kiểm soát điều này, trong khi ở những người khác mà bạn không thể.
In a given editor, a tab might be 8 spaces or it might be 2.
In some editors, you can control this, while in others you can't.

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

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

Đã trả lời ngày 23 tháng 9 năm 2008 lúc 13:25Sep 23, 2008 at 13:25

BenoitbenoitBenoit

36,9K24 Huy hiệu vàng81 Huy hiệu bạc114 Huy hiệu đồng24 gold badges81 silver badges114 bronze badges

3

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

Vấn đề là ... vì chiều rộng của các tab và khoảng trống đều có thể thay đổi - 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 đổ lỗi.

Tôi đồng ý với Jim về điều đó - các tab không phải là xấu xa của chính họ. Nhưng có một vấn đề...

Với không gian, tôi có thể kiểm soát cách "mã của riêng tôi" trông như thế nào trong mọi biên tập viên trên thế giới. Nếu tôi sử dụng 4 khoảng trống - thì bất kể bạn trình chỉnh sửa nào bạn mở mã của tôi, nó sẽ có cùng khoảng cách với lề trái. Với các tab, tôi đang ở trong cài đặt width tab-width cho trình soạn thảo-ngay cả đối với mã của riêng tôi. Và tôi không thích điều đó."MY OWN CODE" looks in EVERY editor in the world. If I use 4 spaces -- then no matter what editor you open my code in, it will have the same distance from the left margin. With tabs I am at the mercy of the tab-width setting for the editor -- even for MY OWN CODE. And I don't like that.

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 họ cũng đủ khả năng cho bạn quyền kiểm soát nhiều hơn về giao diện của riêng 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 các lập trình viên viết mã - nhưng tính nhất quán trong các biên tập viên cho thấy mã đó - rằng không gian dễ dàng đạt được (và áp đặt).

Đã trả lời ngày 6 tháng 8 năm 2011 lúc 6:53Aug 6, 2011 at 6:53

TreeCodertreecodertreecoder

40.9K22 Huy hiệu vàng64 Huy hiệu bạc89 Huy hiệu đồng22 gold badges64 silver badges89 bronze badges

4

Chà, tôi sẽ nói rằng không có "đề xuất" như vậy trong PEP 8. Nó được nêu như một khuyến nghị vì chúng sẽ không cấm bạn viết các tab nhưng vì mã phải được viết theo cách tiêu chuẩn nhất, sử dụng không gian chúng ta phải .

Điều đó nói rằng, nếu tôi là người viết hướng dẫn tiêu chuẩn, tôi sẽ giới thiệu các tab vì chúng là một cách hiện đại và thiết thực hơn để thụt mã.

Cuối cùng, tôi sẽ nhấn mạnh, tôi không khuyến khích bất kỳ ai sử dụng các tab, thay vào đó, tôi đang nói rằng tất cả chúng ta nên sử dụng không gian như đã nêu trong hướng dẫn kiểu.not encouraging anybody to use tabs, instead, I am saying that all of us should use spaces as stated in the style guide.

Đã trả lời ngày 14 tháng 1 năm 2021 lúc 19:33Jan 14, 2021 at 19:33

Làm thế nào để bạn chèn một tab trong Python?

Làm thế nào để các tab hoạt động trong Python?

Làm thế nào để bạn in một tab trong Python?

Bạn có thể thụt vào trong Python?