Jaka jest konwencja nazewnictwa w Pythonie dla nazw zmiennych i funkcji?

Pochodząca z tła C # konwencja nazewnictwa zmiennych i nazw metod to zwykle camelCase lub PascalCase:

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

W Pythonie widziałem powyższe, ale widziałem także używane podkreślenia:

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

Czy istnieje bardziej preferowany, ostateczny styl kodowania dla Pythona?

Zobacz Python PEP 8: Nazwy funkcji i zmiennych :

Nazwy funkcji powinny być pisane małymi literami, w razie potrzeby słowa oddzielane podkreślnikami, aby poprawić czytelność.

Nazwy zmiennych są zgodne z tą samą konwencją co nazwy funkcji.

MixedCase jest dozwolony tylko w kontekstach, w których jest to już dominujący styl (np. threading.py ), aby zachować kompatybilność wsteczną.

Google Python Style Guide ma następującą konwencją:

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.

Podobny schemat nazewnictwa należy zastosować do CLASS_CONSTANT_NAME

David Goodger (w „Code Like a Pythonista” tutaj ) opisuje zalecenia PEP 8 w następujący sposób:

• joined_lower dla funkcji, metod, atrybutów, zmiennych

• joined_lowerlub ALL_CAPSdla stałych

• StudlyCaps na zajęcia

• camelCase tylko w celu zachowania zgodności z wcześniej istniejącymi konwencjami

Jak przyznaje przewodnik po stylu dla kodu Python ,

Konwencje nazewnictwa w bibliotece Pythona to trochę bałagan, więc nigdy nie uzyskamy tego całkowicie spójnego

Zauważ, że odnosi się to tylko do standardowej biblioteki Pythona . Jeśli nie są w stanie uzyskać takiej spójności, nie ma prawie żadnej nadziei na przyjęcie ogólnie przyjętej konwencji dla całego kodu Pythona, prawda?

Z tego i dyskusji tutaj wywnioskowałbym, że to nie jest straszny grzech, jeśli ktoś nadal używa np. (Jasnych i dobrze ugruntowanych) konwencji nazewnictwa dla zmiennych i funkcji przy przechodzeniu do Pythona. Pamiętając oczywiście, że najlepiej postępować zgodnie z dominującym stylem bazy kodu / projektu / zespołu. Jak wskazuje Przewodnik po stylu Python, najważniejsza jest spójność wewnętrzna .

^{Odrzuć mnie jako heretyka. :-) Podobnie jak OP, nie jestem „Pythonistą”, jeszcze nie.}

Istnieje PEP 8 , jak pokazują inne odpowiedzi, ale PEP 8 jest tylko przewodnikiem po stylach dla standardowej biblioteki i jest w niej tylko ewangelią. Jednym z najczęstszych odchyleń PEP 8 dla innych fragmentów kodu jest nazywanie zmiennych, szczególnie dla metod. Nie ma jednego dominującego stylu, chociaż biorąc pod uwagę objętość kodu, który używa mixedCase, gdyby wykonać ścisły spis, prawdopodobnie powstałaby wersja PEP 8 z mixedCase. Istnieje niewiele innych odchyleń od PEP 8, które są równie powszechne.

Jak wspomniano, PEP 8 mówi o używaniu lower_case_with_underscoreszmiennych, metod i funkcji.

Wolę używać lower_case_with_underscoreszmiennych, a także mixedCasemetod i funkcji, aby kod był bardziej wyraźny i czytelny. Zatem podążanie za Zenem Pythona „wyraźne jest lepsze niż niejawne” i „liczy się czytelność”

w odpowiedzi na odpowiedź @JohnTESlade. Przewodnik po stylu pythonowym Google zawiera kilka fajnych rekomendacji,

Nazwy, których należy unikać

• nazwy pojedynczych znaków, z wyjątkiem liczników lub iteratorów
• myślniki (-) w nazwie dowolnego pakietu / modułu
• \__double_leading_and_trailing_underscore__ names (zarezerwowane przez Python)

Konwencja nazewnictwa

• „Wewnętrzny” oznacza wewnętrzny moduł lub chroniony lub prywatny w klasie.
• Przygotowanie pojedynczego podkreślenia (_) ma pewne wsparcie dla ochrony zmiennych i funkcji modułu (nie dołączone do importu * z). Przygotowanie podwójnego podkreślenia (__) do zmiennej instancji lub metody skutecznie służy do uczynienia zmiennej lub metody prywatną dla swojej klasy (przy użyciu manglingu nazw).
• Umieść powiązane klasy i funkcje najwyższego poziomu razem w module. W przeciwieństwie do Javy nie ma potrzeby ograniczania się do jednej klasy na moduł.
• Użyj CapWordsdla nazw klas, ale lower_with_under.pydla nazw modułów. Chociaż istnieje wiele istniejących modułów o CapWords.pytej nazwie , jest to odradzane, ponieważ jest mylące, gdy moduł nazywa się po klasie. („czekaj - pisałem import StringIOczy from StringIO import StringIO?”)

Wytyczne oparte na zaleceniach Guido

Większość ludzi w Pythonie woli podkreślenia, ale nawet ja używam Pythona od ponad 5 lat, nadal ich nie lubię. Po prostu wyglądają dla mnie brzydko, ale może to wszystko Java w mojej głowie.

Po prostu lubię CamelCase, ponieważ lepiej pasuje do sposobu, w jaki nazywane są klasy. To bardziej logiczne SomeClass.doSomething()niż mieć SomeClass.do_something(). Jeśli rozejrzysz się w globalnym indeksie modułów w pythonie, znajdziesz oba, co wynika z faktu, że jest to zbiór bibliotek z różnych źródeł, które rosły z czasem, a nie coś, co zostało opracowane przez jedną firmę, np. Sun, z surowymi regułami kodowania . Powiedziałbym, że sedno brzmi: Użyj tego, co lubisz lepiej, to tylko kwestia osobistego gustu.

Osobiście staram się używać CamelCase do klas, metod i funkcji mixedCase. Zmienne są zwykle oddzielane podkreśleniem (kiedy pamiętam). W ten sposób mogę na pierwszy rzut oka powiedzieć, do czego dokładnie dzwonię, a nie wszystko wygląda tak samo.

Jest artykuł na ten temat: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Mówi, że snake_case jest bardziej czytelny niż camelCase. Dlatego współczesne języki używają (lub powinny) używać węża tam, gdzie to możliwe.

Styl kodowania jest zwykle częścią wewnętrznych standardów polityki / konwencji organizacji, ale myślę, że generalnie styl all_lower_case_underscore_separator (zwany również snake_case) jest najczęściej spotykany w pythonie.

Osobiście korzystam z konwencji nazewnictwa Java podczas programowania w innych językach programowania, ponieważ jest on spójny i łatwy do naśladowania. W ten sposób nie nieustannie walczę o to, jakich konwencji użyć, co nie powinno być najtrudniejszą częścią mojego projektu!

Zazwyczaj stosuje się konwencje stosowane w standardowej bibliotece języka.