Değişken ve işlev adları için Python'da adlandırma kuralı nedir?

Bir C # arka planından gelen değişkenler ve yöntem adları için adlandırma kuralı genellikle camelCase veya PascalCase'dir:

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

Python'da, yukarıdakileri gördüm ama alt çizgilerin kullanıldığını da gördüm:

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

Python için daha çok tercih edilen, kesin bir kodlama stili var mı?

Bkz. Python PEP 8: İşlev ve Değişken İsimleri :

İşlev adları okunabilirliği artırmak için kelimeler alt çizgilerle ayrılmış küçük harflerle yazılmalıdır .

Değişken adları işlev adlarıyla aynı kuralı izler.

mixedCase , geriye dönük uyumluluğu korumak için yalnızca geçerli stil olan bağlamlarda (örneğin, threading.py ) izin verilir .

Google Python Stil Kılavuzu Şu düzeni vardır:

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.

Benzer bir adlandırma şeması bir CLASS_CONSTANT_NAME

( "Kod gibi Pythonista" David Goodger burada şöyle) Pep 8 öneriler açıklar:

• joined_lower fonksiyonlar, yöntemler, nitelikler, değişkenler için

• joined_lowerveya ALL_CAPSsabitler için

• StudlyCaps sınıflar için

• camelCase sadece önceden var olan sözleşmelere uymak için

As Python Kodu için Stil Kılavuzu , itiraf

Python kütüphanesinin adlandırma kuralları biraz karışıktır, bu yüzden bunu asla tamamen tutarlı hale getirmeyeceğiz

Bunun sadece Python'un standart kütüphanesine atıfta bulunduğunu unutmayın . Eğer bunu tutarlı kılamazlarsa, tüm Python kodları için genel olarak uyulması gereken bir konvansiyona sahip olma umudu pek yoktur, değil mi?

Bu itibaren ve burada tartışma, bunun olduğunu anlamak istiyorum değil birini kullanarak devam ederse korkunç günah Örneğin Java en veya C # 'ın (açık ve köklü) Python yanına geçerken değişkenler ve fonksiyonlar için adlandırma kuralları. Elbette, bir kod tabanı / proje / ekip için hakim olan stilin ne olduğuna uymanın en iyisi olduğunu unutmayın. Python Stil Kılavuzu'nun işaret ettiği gibi, iç tutarlılık en önemli şeydir.

^{Beni bir sapkın olarak reddetmekten çekinmeyin. :-) OP gibi ben zaten bir "Pythonista" değilim.}

Diğer cevapların gösterdiği gibi PEP 8 var , ancak PEP 8 sadece standart kütüphane için stil kılavuzu ve sadece orada müjde olarak alındı. PEP 8'in diğer kod parçaları için en sık sapmalarından biri, özellikle yöntemler için değişken adlandırmadır. Tek bir baskın stil yoktur, ancak mixedCase kullanan kodun hacmi göz önünde bulundurulursa, biri sıkı bir sayım yapacak olsaydı, muhtemelen mixedCase ile PEP 8'in bir sürümü ile sonuçlanacaktır. PEP 8'den oldukça yaygın olan başka bir sapma var.

Belirtildiği gibi, PEP 8 lower_case_with_underscoresdeğişkenler, yöntemler ve fonksiyonlar için kullanıldığını söyler .

Ben lower_case_with_underscoresdeğişkenleri ve mixedCaseyöntem ve fonksiyonlar için kullanmayı tercih kodu daha açık ve okunabilir hale getirir. Böylece Python'un Zen'ini takip etmek “açık, örtük olmaktan iyidir” ve “Okunabilirlik önemlidir”

@JohnTESlade'in yanıtladığı konuya ek olarak. Google'ın python stil kılavuzu oldukça düzgün öneriler var,

Kaçınılması Gereken İsimler

• sayaçlar veya yineleyiciler hariç tek karakter adları
• herhangi bir paket / modül adında tire (-)
• \__double_leading_and_trailing_underscore__ names (Python tarafından ayrılmıştır)

Adlandırma kuralı

• "Dahili", bir modülün içindeki veya bir sınıf içindeki korumalı veya özel anlamına gelir.
• Tek bir alt çizgi (_) eklemek, modül değişkenlerini ve işlevlerini korumak için bazı desteklere sahiptir (içe aktarma * ile dahil değildir). Bir örnek değişkenine veya yönteme bir çift alt çizgi (__) eklemek, değişkeni veya yöntemi kendi sınıfına özel hale getirmeye yarar (ad yönetimi kullanarak).
• İlgili sınıfları ve üst düzey işlevleri bir modüle yerleştirin. Java'nın aksine, modül başına kendinizi bir sınıfla sınırlandırmanıza gerek yoktur.
• CapWordsSınıf adları için, ancak lower_with_under.pymodül adları için kullanın . Mevcut birçok modül olmasına rağmen CapWords.py, bu artık cesaret kırılmıştır çünkü modül bir dersten sonra adlandırıldığında kafa karıştırıcıdır. ("bekle - yazdım mı import StringIOyoksa from StringIO import StringIO?")

Guido'nun Tavsiyelerinden türetilen kılavuzlar

Çoğu python insanı alt çizgileri tercih eder, ancak şu anda 5 yıldan beri python kullanıyorum, yine de onları sevmiyorum. Bana sadece çirkin gözüküyorlar, ama belki de kafamdaki tüm Java.

CamelCase'i daha iyi seviyorum çünkü sınıfların isimlendirilmesiyle daha iyi uyuyor, Sahip SomeClass.doSomething()olmaktan daha mantıklı geliyor SomeClass.do_something(). Python'daki küresel modül dizinine bakarsanız, her ikisini de bulacaksınız; . Sonuç olarak şöyle diyorum: İstediğinizi daha iyi kullanın, bu sadece kişisel zevk meselesidir.

Şahsen CamelCase'i sınıflar, mixedCase yöntemleri ve işlevleri için kullanmaya çalışıyorum. Değişkenler genellikle alt çizgi ile ayrılır (hatırlayabildiğimde). Bu şekilde, her şeye aynı görünmek yerine tam olarak ne dediğimi bir bakışta anlatabilirim.

Bununla ilgili bir makale var: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Snake_case'in camelCase'den daha okunabilir olduğunu söylüyor. Bu yüzden modern diller her yerde yılan kullanır (veya kullanmalıdır).

Kodlama stili genellikle bir kuruluşun iç politika / konvansiyon standartlarının bir parçasıdır, ancak genel olarak all_lower_case_underscore_separator stili (yılan_case olarak da bilinir) python'da en yaygın olanıdır.

Ben tutarlı ve takip edilmesi kolay olduğu için diğer programlama dillerinde geliştirirken Java'nın adlandırma kurallarını şahsen kullanıyorum. Bu şekilde, projemin en zor kısmı olmaması gereken hangi sözleşmeleri kullanacağım konusunda sürekli mücadele etmiyorum!

Tipik olarak, dilin standart kütüphanesinde kullanılan kurallara uyulur.