2009-07-14 33 views
48

Khi mã hóa python, tôi chỉ sử dụng 2 dấu cách để thụt lề, chắc chắn PEP-8 thực sự khuyên bạn nên có 4 dấu cách, nhưng về mặt lịch sử đối với tôi thì nó không bình thường.Python: sử dụng 4 dấu cách cho thụt lề. Tại sao?

Vì vậy, bất kỳ ai cũng có thể thuyết phục tôi sử dụng 4 dấu cách thay vì 2 không? Ưu và khuyết điểm gì?

P.S. Và cuối cùng, cách dễ dàng để chuyển đổi tất cả các codebase hiện có từ 2 khoảng cách thành 4 không gian là gì?


P.P.S. PEP-8 Cũng khuyên bạn không nên sử dụng các tab để lưu ý. read here


Vì vậy, để tóm tắt:

Ưu điểm:

  • Có nhiều không gian để sắp xếp khi wraping chuỗi dài hơn 80 dòng.
  • Có thể sao chép mã từ các đoạn mã và nó hoạt động.

Nhược điểm:

  • Với mức sâu sắc hơn về báo cáo lồng nhau bạn có ít không gian cho mã thực tế.

Cảm ơn.

+6

Bạn sẽ muốn tạo một cộng đồng wiki này hoặc điều này có thể sẽ bị đóng. Đây là một chủ đề gây tranh cãi cao mà mọi người đều có ý kiến ​​riêng. – MitMaro

+0

@MitMaro: Tôi đồng ý rằng điều này là rất chủ quan; mặc dù đáng chú ý là P.S. một phần là một câu hỏi hợp lệ. – DrAl

+0

@AI: Nên có hai câu hỏi riêng biệt – MitMaro

Trả lời

79

Mọi người khác sử dụng 4 dấu cách. Đó là lý do duy nhất để sử dụng 4 không gian mà tôi đã gặp và chấp nhận. Trong trái tim tôi, tôi vẫn muốn sử dụng các tab (1 ký tự thụt lề cho mỗi thụt lề, có ý nghĩa, không? Riêng biệt thụt lề từ khoảng trắng khác. Tôi không quan tâm rằng các tab có thể là hiển thị như độ rộng khác nhau. Điều tồi tệ nhất có thể xảy ra là một số ý kiến ​​không xếp hàng. Kinh dị!) Nhưng tôi đã chấp nhận rằng kể từ khi cộng đồng python nói chung sử dụng 4 không gian, tôi sử dụng 4 dấu cách. Bằng cách này, tôi có thể tập hợp mã từ các đoạn mã khác mà người khác đã viết và tất cả đều hoạt động.

+2

Tôi nghĩ bạn có nghĩa là 4 không gian, không phải 4 tab;) – fortran

+0

d'oh. Đã sửa. :) – Markus

+17

"Bằng cách này, tôi có thể tập hợp mã từ các đoạn trích khác mà người khác đã viết và tất cả đều hoạt động ..." VÀ có vẻ như là mã _my_ :) – xtofl

4

Nếu bạn là người lập trình duy nhất làm việc trên tệp nguồn của mình và không có tiêu chuẩn mã hóa nào thực thi một kiểu cụ thể, hãy sử dụng bất cứ điều gì bạn cảm thấy thoải mái. Cá nhân (và phù hợp với tiêu chuẩn mã hóa của chúng tôi), tôi sử dụng các tab cứng để bất kỳ ai đang xem mã có thể sử dụng tùy chọn của riêng họ.

Để thực hiện thay đổi, bạn chỉ cần thay đổi tất cả các không gian bắt đầu dòng thành những khoảng trống lớn gấp hai lần. Có rất nhiều cách để làm điều này; trong trình soạn thảo văn bản Vim, tôi có thể nghĩ đến hai: thứ nhất:

:%s/^\(\s\{2}\)\+/\=repeat(' ', len(submatch(0))*2) 

Đây là một biểu hiện thường xuyên đơn giản mà trông cho một hoặc nhiều cặp không gian vào lúc bắt đầu của dòng và thay thế chúng với hai lần như nhiều không gian như đã được tìm thấy. Nó có thể được mở rộng để làm tất cả các file bằng cách mở vim với:

vim *.py 

(hoặc tương đương), tiếp theo là (chưa được kiểm tra):

:argdo %s/^\(\s\{2}\)\+/\=repeat(' ', len(submatch(0))*2)/ | w 

Hoặc:

" Switch to hard tabs: 
:set noexpandtab 
" Set the tab stop to the current setting 
:set tabstop=2 
" Change all spaces to tabs based on tabstop 
:retab! 
" Change the tab stop to the new setting 
:set tabstop=4 
" Go back to soft tabs 
:set expandtab 
" Replace all the tabs in the current file to spaces 
:retab 

Dĩ nhiên , nhiều công cụ khác sẽ cung cấp các tính năng tương tự: Tôi sẽ ngạc nhiên nếu một cái gì đó như sed, awk, perl hoặc python không thể thực hiện điều này .

2

Tiêu chuẩn về nhận dạng và mã hóa chung thay đổi từ ngôn ngữ này sang ngôn ngữ, dự án khác. Có một lý do để áp dụng tiêu chuẩn kiểu mã hóa: để mã trông đồng nhất, bất kể ai đã viết nó. Điều đó cải thiện mức độ dễ đọc trong dự án, và, để nói thẳng thắn, có vẻ tốt hơn.

Có một lý do không hợp lệ khi áp dụng tiêu chuẩn kiểu mã hóa: vì bạn thích nó. Các tiêu chuẩn mã hóa tồn tại một cách chính xác bởi vì sở thích của con người thay đổi, và nếu để lại cho riêng mình, sự hỗn loạn sẽ xảy ra, gây tổn hại cho tất cả mọi người.

Nếu bạn đang viết mã cho chính mình, không ai sẽ đọc, hãy tiếp tục và viết nó bất cứ điều gì bạn thích. Nếu không, theo tiêu chuẩn được chấp nhận của cộng đồng của bạn sẽ làm cho mã của bạn dễ chịu hơn nhiều đối với mắt của mọi người. Và hãy nhớ rằng, nếu bạn quyết định đóng góp mã cho một cộng đồng trong tương lai, bạn sẽ có một thời gian dễ dàng hơn nếu bạn đã quen với phong cách mã hóa của họ rồi.

Để thay đổi kích thước tab, có nhiều trình định dạng mã nguồn có hỗ trợ Python, và hầu hết các trình soạn thảo và IDE của lập trình viên cũng có khả năng này. Bạn có thể đã có nó, nó chỉ là vấn đề tư vấn tài liệu cho trình soạn thảo bạn đang sử dụng.

11

Không có "thụt đầu dòng" tốt hơn. Đó là một chủ đề thánh chiến. Bốn là tốt đẹp bởi vì nó đủ để làm cho thụt đầu dòng rõ ràng, nhưng không quá nhiều mà toàn bộ màn hình của bạn chủ yếu là khoảng trắng và bạn phải cuộn theo chiều ngang để đọc một nửa chương trình.

Nó cũng có ưu điểm là một "nửa tab" với định nghĩa lịch sử của "tab".

Ngoài ra, hãy sử dụng bất kỳ nhóm nào bạn thích. Nó giống như sô cô la so với vani.

Cách dễ dàng để chuyển đổi là sử dụng trình chỉnh sửa có hỗ trợ tab và không gian. Chuyển đổi tất cả các tab không gian hàng đầu của bạn thành tab, đặt kích thước tab thành bốn tab và sau đó chuyển đổi tab hàng đầu trở lại tab không gian.

Khá dễ thực hiện với tập lệnh python. Chỉ cần đếm tất cả các không gian hàng đầu, sau đó thêm cùng một số tiền vào đầu dòng và viết nó trở lại.

+0

Chúng tôi đã làm điều tương tự trong Emacs. Bằng cách đó, các lập trình viên có thể thấy khoảng cách mà họ ưa thích mà không phải ép buộc nó vào phần còn lại của nhóm. –

7

PEP không phải là ông chủ của bạn. Nếu nó đã liên tục thụt lề 2 dấu cách, không có lý do gì để thay đổi tất cả mã của bạn để phù hợp với nó. Bạn có thể làm theo nó về phía trước nếu bạn thực sự nghĩ rằng đó là quan trọng, nhưng, thẳng thắn, tôi không. Bạn tốt hơn là đi với bất kỳ quy ước cung cấp cho bạn (và đồng nghiệp của bạn) sự thoải mái nhất cả về đọc và viết.

26

Tôi nghĩ câu hỏi thực sự là tại sao không gian và không phải là tab.

Tabs rõ ràng là tốt hơn:

  • Nó làm cho gần không thể có mâu thuẫn thụt đầu dòng (Tôi đã nhìn thấy mã mà thường có 4 chỗ indents, nhưng sau đó một số bộ phận xảy ra được một không gian hết, đó là khó kiểm tra bằng cách kiểm tra đơn giản nếu có 7 hoặc 8 dấu cách ... Điều đó sẽ không xảy ra với các tab, trừ khi bạn đặt tabstop thành 1 không gian).
  • Tab là một logic ngữ nghĩa đại diện cho indentation, nó cho phép bạn (và bất kỳ nhà phát triển khác) để lựa chọn để hiển thị như nhiều "khoảng trống" (hay đúng hơn là cột) mà bạn muốn mà không phiền với sở thích của người khác.
  • Nó cũng là ít tổ hợp phím hơn nếu bạn chỉ có "notepad" (hoặc trình chỉnh sửa giả khác) trong tầm tay.
  • Thêm và xóa tab là hoạt động đối xứng đối xứng. Hầu hết IDE có thể tự động chèn 4 dấu cách khi nhấn phím tab, nhưng thường chúng chỉ xóa 1 dấu cách khi nhấn phím lùi (thao tác không thụt lề vẫn có thể truy cập dưới dạng shift-tab, nhưng đó là kết hợp hai phím) hoặc bạn sử dụng chuột để nhấp ở giữa thụt đầu dòng và xóa một ký tự.
  • Chỉ mất 1 byte thay vì 4 (nhân với hàng nghìn dòng và bạn tiết kiệm được một vài KB!: P)
  • Bạn có một điều ít hơn để giải quyết thỏa thuận, bởi vì nếu bạn quyết định đi vào không gian thì cuộc thảo luận bắt đầu một lần nữa để chọn bao nhiêu (mặc dù sự đồng thuận dường như là khoảng bốn).

Ưu điểm của không gian:

  • Guido thích chúng.
  • Bạn không thể dễ dàng nhập tab ở đây, nó sẽ chuyển tiêu điểm (mặc dù bạn có thể dán tiêu điểm).
+2

Tôi thích cách bạn nói nó chuyển trọng tâm. –

0

sử dụng 4 dấu cách hoặc 2 dấu cách hoàn toàn tùy thuộc vào bạn. 4 không gian chỉ là một quy ước. Điều quan trọng nhất, không trộn lẫn các tab và dấu cách. Sử dụng thanh không gian

6

Bất kỳ trình soạn thảo phong nha nào (emacs, vim) sẽ trừu tượng toàn bộ điều vô nghĩa này cho bạn. Nó sẽ làm việc tốt như nhau với không gian hoặc tab, và nó có thể được cấu hình để sử dụng bất kỳ số lượng không gian (hoặc bất kỳ số lượng chiều rộng không gian cho một nhân vật tab). Nó cũng có thể chuyển đổi giữa các định dạng khác nhau mà không gặp quá nhiều rắc rối (xem lệnh :retab trong vim).

Nếu bạn đang cố gắng chuyển đổi hàng loạt định dạng nguồn, tôi khuyên bạn nên xem tiện ích indent.

Điều đó nói rằng, tôi không thể cưỡng lại trả lời câu hỏi khác ... Sở thích của tôi luôn là tab, vì nó bỏ qua toàn bộ vấn đề và mọi người có thể xem mã nguồn với độ rộng được thiết lập phù hợp. Nó cũng ít gõ hơn khi bạn làm việc trong các trình soạn thảo không hữu ích khi chuyển đổi nó. Theo như 2 vs 4 không gian, đó hoàn toàn là mỹ phẩm.

2

Một lý do là nếu bạn sử dụng ít khoảng trống hơn cho thụt đầu dòng, bạn sẽ có thể lồng nhiều câu lệnh hơn (vì độ dài dòng thường được giới hạn ở 80).

Bây giờ tôi khá chắc chắn rằng một số người vẫn không đồng ý về số lượng cấu trúc lồng nhau sẽ là tối đa.

55

Tôi thích thực tế là bốn ký tự khoảng trắng độc đáo thụt vào mã bên trong của hàm, vì def + một khoảng trắng tạo thành bốn ký tự.

def·foo(): 
····pass 
5

Ngoài ra một trong những lý do là: khi bạn có một số dòng dài (dài hơn 80 ký tự) và muốn chia nó trong 2 bạn sẽ chỉ có 1 không gian để thụt, đó là một chút bối rối:

if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \ 
and someotherstatementhere: 
    # some code inside if block 
    pass 

if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \ 
    and someotherstatementhere: 
    # some code inside if block 
    pass 
+2

Bạn không nên làm điều đó. Nếu thụt đầu dòng của bạn là 4 khoảng trống, bạn sẽ không bao giờ có thụt đầu dòng ít hơn. Theo tôi, dòng "và" được thụt lề thêm hai cấp nữa so với dòng "if". – TimK

1

Nếu bạn muốn viết mã python cùng với các lập trình viên khác, nó sẽ trở thành một vấn đề nếu bạn sử dụng một sự chú ý khác như chúng. Hầu hết các lập trình viên Python có khuynh hướng sử dụng 4 chỗ trống.

1

Việc xác định trực quan các khối mã lồng nhau dài hơn với 4 khoảng trắng sẽ dễ dàng hơn. Tiết kiệm thời gian khi gỡ lỗi.

+0

Đồng ý. Đối với một ngôn ngữ như C tôi muốn sử dụng hai, trên thực tế, nhưng trong C các đầu mối trực quan được cung cấp bởi thụt đầu dòng là ít quan trọng hơn là trong Python. – user1071847

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