Quy ước đặt tên trong Python cho tên biến và hàm là gì?

Đến từ nền C #, quy ước đặt tên cho các biến và tên phương thức thường là camelCase hoặc PascalCase:

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

Trong Python, tôi đã thấy ở trên nhưng tôi cũng đã thấy dấu gạch dưới được sử dụng:

# python example
this_is_my_variable = 'a'
def this_is_my_function():

Có một phong cách mã hóa dứt khoát, thích hợp hơn cho Python không?

Xem Python PEP 8: Tên hàm và biến :

Tên hàm nên được viết thường, với các từ được phân tách bằng dấu gạch dưới khi cần thiết để cải thiện khả năng đọc.

Tên biến theo cùng quy ước như tên hàm.

mixCase chỉ được phép trong các bối cảnh nơi đó đã là kiểu thịnh hành (ví dụ: threading.py ), để duy trì khả năng tương thích ngược.

Các Google Python Style Guide có quy ước sau:

module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name.

Một kế hoạch đặt tên tương tự nên được áp dụng cho một CLASS_CONSTANT_NAME

David Goodger (trong "Code Like a Pythonista" ở đây ) mô tả các đề xuất PEP 8 như sau:

• joined_lower cho các hàm, phương thức, thuộc tính, biến

• joined_lowerhoặc ALL_CAPScho hằng số

• StudlyCaps cho các lớp học

• camelCase chỉ để phù hợp với các công ước đã có từ trước

Như Hướng dẫn về Phong cách cho Mã Python thừa nhận,

Các quy ước đặt tên của thư viện Python là một mớ hỗn độn, vì vậy chúng tôi sẽ không bao giờ có được điều này hoàn toàn nhất quán

Lưu ý rằng điều này chỉ liên quan đến thư viện tiêu chuẩn của Python . Nếu họ không thể có được sự nhất quán đó, thì hầu như không có nhiều hy vọng có một quy ước được tuân thủ chung cho tất cả các mã Python, phải không?

Từ đó và thảo luận ở đây, tôi sẽ suy luận rằng đó không phải là một tội lỗi khủng khiếp nếu người ta cứ sử dụng các quy ước đặt tên của Java hoặc C # (rõ ràng và được thiết lập tốt) cho các biến và hàm khi chuyển qua Python. Tất nhiên, hãy nhớ rằng tốt nhất là tuân theo bất cứ phong cách phổ biến nào cho một codebase / dự án / nhóm xảy ra. Như Hướng dẫn về Phong cách Python chỉ ra, tính nhất quán bên trong là quan trọng nhất.

^{Hãy loại bỏ tôi như một kẻ dị giáo. :-) Giống như OP, dù sao tôi cũng không phải là "Pythonista".}

Có PEP 8 , như các câu trả lời khác cho thấy, nhưng PEP 8 chỉ là phong cách cho thư viện tiêu chuẩn và nó chỉ được coi là phúc âm trong đó. Một trong những sai lệch thường gặp nhất của PEP 8 đối với các đoạn mã khác là cách đặt tên biến, đặc biệt cho các phương thức. Không có kiểu chiếm ưu thế duy nhất, mặc dù xem xét khối lượng mã sử dụng hỗn hợp, nếu một người thực hiện một điều tra dân số nghiêm ngặt, người ta có thể sẽ kết thúc bằng một phiên bản PEP 8 với hỗn hợp. Có rất ít sai lệch khác so với PEP 8 khá phổ biến.

Như đã đề cập, PEP 8 nói sẽ sử dụng lower_case_with_underscorescho các biến, phương thức và hàm.

Tôi thích sử dụng lower_case_with_underscorescho các biến và mixedCasecho các phương thức và hàm làm cho mã rõ ràng và dễ đọc hơn. Do đó, theo Zen "của Python là tốt hơn so với ngầm" và "Số lượng khả năng đọc"

hơn nữa với những gì @JohnTESlade đã trả lời. Hướng dẫn phong cách python của Google có một số đề xuất khá gọn gàng,

Tên cần tránh

• tên nhân vật duy nhất ngoại trừ bộ đếm hoặc lặp
• dấu gạch ngang (-) trong bất kỳ tên gói / mô-đun nào
• \__double_leading_and_trailing_underscore__ names (được bảo lưu bởi Python)

Quy ước đặt tên

• "Internal" có nghĩa là nội bộ cho một mô-đun hoặc được bảo vệ hoặc riêng tư trong một lớp.
• Chuẩn bị một dấu gạch dưới đơn (_) có một số hỗ trợ để bảo vệ các biến và chức năng của mô-đun (không bao gồm nhập * từ). Chuẩn bị một dấu gạch dưới kép (__) cho một biến đối tượng hoặc phương thức phục vụ hiệu quả để biến biến hoặc phương thức thành riêng tư đối với lớp của nó (sử dụng xáo trộn tên).
• Đặt các lớp liên quan và các hàm cấp cao nhất với nhau trong một mô-đun. Không giống như Java, không cần giới hạn bản thân trong một lớp cho mỗi mô-đun.
• Sử dụng CapWordscho tên lớp, nhưng lower_with_under.pycho tên mô-đun. Mặc dù có nhiều mô-đun hiện có được đặt tên CapWords.py, nhưng điều này hiện không được khuyến khích vì thật khó hiểu khi mô-đun xảy ra được đặt tên theo một lớp. ("chờ đã - tôi đã viết import StringIOhay from StringIO import StringIOchưa?")

Nguyên tắc bắt nguồn từ Khuyến nghị của Guido

Hầu hết những người dùng trăn đều thích quần lót, nhưng ngay cả tôi cũng đang sử dụng python từ hơn 5 năm nay, tôi vẫn không thích chúng. Chúng trông thật xấu xí đối với tôi, nhưng có lẽ đó là tất cả Java trong đầu tôi.

Tôi chỉ đơn giản như CamelCase tốt hơn vì nó phù hợp hơn với cách lớp học được đặt tên, Nó cảm thấy hợp lý hơn để có SomeClass.doSomething()hơn SomeClass.do_something(). Nếu bạn nhìn xung quanh chỉ số mô-đun toàn cầu bằng python, bạn sẽ tìm thấy cả hai, đó là do thực tế đó là một tập hợp các thư viện từ nhiều nguồn phát triển ngoài giờ và không phải là thứ được phát triển bởi một công ty như Sun với các quy tắc mã hóa nghiêm ngặt . Tôi muốn nói điểm mấu chốt là: Sử dụng bất cứ thứ gì bạn thích hơn, đó chỉ là một câu hỏi về sở thích cá nhân.

Cá nhân tôi cố gắng sử dụng CamelCase cho các lớp, các phương thức và hàm hỗn hợp. Các biến thường được phân tách bằng dấu gạch dưới (khi tôi có thể nhớ). Bằng cách này tôi có thể nói trong nháy mắt chính xác những gì tôi đang gọi, hơn là mọi thứ trông giống nhau.

Có một bài viết về điều này: http://www.cs.kent.edu/~jmaletic/ con / ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Nó nói rằng Snake_case dễ đọc hơn camelCase. Đó là lý do tại sao các ngôn ngữ hiện đại sử dụng (hoặc nên sử dụng) con rắn bất cứ nơi nào chúng có thể.

Kiểu mã hóa thường là một phần của các tiêu chuẩn chính sách / quy ước nội bộ của một tổ chức, nhưng tôi nghĩ nói chung, kiểu all_lower_case_underscore_separator (còn gọi là Snake_case) là phổ biến nhất trong python.

Cá nhân tôi sử dụng các quy ước đặt tên của Java khi phát triển bằng các ngôn ngữ lập trình khác vì nó phù hợp và dễ làm theo. Bằng cách đó, tôi không tiếp tục đấu tranh về việc sử dụng những quy ước nào không phải là phần khó nhất trong dự án của tôi!

Thông thường, người ta tuân theo các quy ước được sử dụng trong thư viện tiêu chuẩn của ngôn ngữ.