Qual è la convenzione di denominazione in Python per nomi di variabili e funzioni?

Proveniente da uno sfondo C #, la convenzione di denominazione per variabili e nomi di metodi è generalmente camelCase o PascalCase:

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

In Python, ho visto quanto sopra ma ho anche visto i trattini bassi usati:

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

Esiste uno stile di codifica più preferibile e definitivo per Python?

Vedi Python PEP 8: nomi di funzioni e variabili :

I nomi delle funzioni devono essere minuscoli, con le parole separate da caratteri di sottolineatura, se necessario per migliorare la leggibilità.

I nomi delle variabili seguono la stessa convenzione dei nomi delle funzioni.

mixedCase è consentito solo in contesti in cui è già lo stile prevalente (ad esempio threading.py ), per mantenere la compatibilità con le versioni precedenti.

La Guida allo stile di Google Python ha la seguente convenzione:

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.

Uno schema di denominazione simile dovrebbe essere applicato a CLASS_CONSTANT_NAME

David Goodger (in "Code Like a Pythonista" qui ) descrive le raccomandazioni di PEP 8 come segue:

• joined_lower per funzioni, metodi, attributi, variabili

• joined_lowero ALL_CAPSper costanti

• StudlyCaps per le lezioni

• camelCase solo per conformarsi alle convenzioni preesistenti

Come ammette la Guida di stile per Python Code ,

Le convenzioni di denominazione della libreria di Python sono un po 'un casino, quindi non riusciremo mai a renderlo completamente coerente

Nota che questo si riferisce solo alla libreria standard di Python . Se non riescono a essere così coerenti, allora non c'è molta speranza di avere una convenzione generalmente rispettata per tutto il codice Python, vero?

Da ciò, e dalla discussione qui, desidero dedurre che non è un peccato orribile se si continuano ad usare ad esempio le convenzioni di denominazione di Java o C # (chiare e consolidate) per variabili e funzioni quando si passa a Python. Ricordando, ovviamente, che è meglio attenersi a qualunque sia lo stile prevalente per una base di codice / progetto / squadra. Come sottolinea la Python Style Guide, la coerenza interna conta di più.

^{Sentiti libero di licenziarmi come eretico. :-) Come l'OP, non sono un "Pythonista", non ancora.}

C'è PEP 8 , come mostrano altre risposte, ma PEP 8 è solo la styleguide per la libreria standard, ed è presa solo come vangelo in essa. Una delle deviazioni più frequenti di PEP 8 per altre parti di codice è la denominazione variabile, in particolare per i metodi. Non esiste un unico stile predominante, anche se considerando il volume di codice che utilizza mixedCase, se si effettuasse un censimento rigoroso si finirebbe probabilmente con una versione di PEP 8 con mixedCase. C'è poca altra deviazione dal PEP 8 che è abbastanza comune.

Come accennato, PEP 8 dice di usare lower_case_with_underscoresper variabili, metodi e funzioni.

Preferisco usare lower_case_with_underscoresper variabili e mixedCaseper metodi e funzioni che rendono il codice più esplicito e leggibile. Quindi seguendo lo Zen di Python "esplicito è meglio che implicito" e "Contabilità"

oltre a ciò che ha risposto @JohnTESlade. La guida allo stile di Python di Google ha alcuni consigli piuttosto accurati,

Nomi da evitare

• nomi di caratteri singoli tranne contatori o iteratori
• trattini (-) in qualsiasi nome di pacchetto / modulo
• \__double_leading_and_trailing_underscore__ names (riservato da Python)

Convenzione di denominazione

• "Interno" significa interno a un modulo o protetto o privato all'interno di una classe.
• La preparazione di un singolo carattere di sottolineatura (_) ha un certo supporto per la protezione delle variabili e delle funzioni del modulo (non incluse con import * da). La preparazione di un carattere di sottolineatura doppio (__) a una variabile o metodo di istanza serve effettivamente a rendere la variabile o il metodo privati ​​per la sua classe (usando la modifica del nome).
• Metti insieme le classi e le funzioni di livello superiore in un modulo. A differenza di Java, non è necessario limitarsi a una classe per modulo.
• Utilizzare CapWordsper i nomi delle classi, ma lower_with_under.pyper i nomi dei moduli. Sebbene ci siano molti moduli esistenti denominati CapWords.py, questo è ora scoraggiato perché è confuso quando il modulo viene chiamato dopo una classe. ("aspetta - ho scritto import StringIOo from StringIO import StringIO?")

Linee guida derivate dalle raccomandazioni di Guido

La maggior parte delle persone di Python preferisce i caratteri di sottolineatura, ma anche io uso Python da più di 5 anni in questo momento, ancora non mi piacciono. Mi sembrano solo brutti, ma forse è tutta la Java nella mia testa.

Ho semplicemente come CamelCase meglio dato che si adatta meglio con il modo in cui le classi sono chiamate, ci si sente più logico avere SomeClass.doSomething()rispetto SomeClass.do_something(). Se ti guardi intorno nell'indice del modulo globale in Python, troverai entrambi, il che è dovuto al fatto che è una raccolta di librerie da varie fonti che sono cresciute negli straordinari e non qualcosa che è stato sviluppato da un'azienda come Sun con rigide regole di codifica . Direi che la linea di fondo è: usa quello che ti piace di più, è solo una questione di gusti personali.

Personalmente provo ad usare CamelCase per classi, metodi e funzioni mixedCase. Le variabili di solito sono sottolineate da caratteri separati (quando posso ricordare). In questo modo posso dire a colpo d'occhio cosa sto esattamente chiamando, piuttosto che tutto sembra uguale.

C'è un articolo su questo: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Dice che snake_case è più leggibile di camelCase. Ecco perché le lingue moderne usano (o dovrebbero usare) il serpente dove possono.

Lo stile di codifica di solito fa parte degli standard di politica interna / convenzione di un'organizzazione, ma penso in generale, lo stile all_lower_case_underscore_separator (chiamato anche snake_case) è più comune in Python.

Personalmente utilizzo le convenzioni di denominazione di Java quando sviluppo in altri linguaggi di programmazione poiché è coerente e facile da seguire. In questo modo non continuo a lottare su quali convenzioni usare che non dovrebbero essere la parte più difficile del mio progetto!

In genere, si seguono le convenzioni utilizzate nella libreria standard del linguaggio.