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

StackOverflow https://stackoverflow.com/questions/159720

Domanda

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

// 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?

È stato utile?

Soluzione

Vedi Python PEP 8 .

  

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

     

mixedCase è consentito solo in contesti   dove è già prevalente   stile

Variabili ...

  

Utilizza le regole di denominazione delle funzioni:   lettere minuscole con parole separate da   sottolinea, se necessario, per migliorare   leggibilità.

Personalmente, mi discosto da questo perché preferisco anche mixedCase rispetto a lower_case per i miei progetti.

Altri suggerimenti

Guida allo stile di Google Python ha la seguente convenzione:

  

nome_modulo, nome_pacchetto, nome classe, nome metodo, nome eccezione,   function_name, GLOBAL_CONSTANT_NAME, global_var_name,   nome_istanza_istanza, nome_parametro_funzione, nome_var_modalità

Uno schema di denominazione simile dovrebbe essere applicato a un CLASS_CONSTANT_NAME

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

  • united_lower per funzioni, metodi, attributi, variabili

  • join_lower o ALL_CAPS per costanti

  • StudlyCaps per le classi

  • camelCase solo per conformarsi convenzioni preesistenti

Come la Guida allo stile per il codice Python ammette,

  

Le convenzioni di denominazione di Python   la libreria è un po 'un casino, quindi lo faremo   mai ottenere questo completamente coerente

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

Da ciò, e la discussione qui, dedurrei che non è non un peccato orribile se si continua ad usare ad es. Convenzioni di denominazione di Java o C # (chiare e consolidate) per variabili e funzioni quando si passa a Python. Tenendo presente, 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 per l'OP, non sono un "Pythonista", non ancora.

Esiste PEP 8 , come mostrano altre risposte, ma PEP 8 è solo la styleguide per la biblioteca 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_underscores per variabili, metodi e funzioni.

Preferisco usare lower_case_with_underscores per variabili e mixedCase per metodi e funzioni rende il codice più esplicito e leggibile. Pertanto, seguire Zen of Python's " esplicito è meglio che implicito " e " Contabilità "

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.

La maggior parte delle persone di Python preferisce i trattini bassi, ma anche io sto usando 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.

Mi piace semplicemente CamelCase perché si adatta meglio al modo in cui vengono denominate le classi. È più logico avere SomeClass.doSomething () che 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 di 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.

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

Nomi da evitare

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

Convenzione sui nomi

  • " interno " significa interno a un modulo o protetto o privato all'interno di una classe.
  • La preparazione di un singolo trattino di sottolineatura (_) ha del supporto per la protezione delle variabili e delle funzioni del modulo (non incluse con import * from). 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 correlate e le funzioni di livello superiore in un modulo. A differenza di Java, non è necessario limitarsi a una classe per modulo.
  • Usa CapWords per i nomi delle classi, ma lower_with_under.py per i nomi dei moduli. Sebbene esistano molti moduli esistenti denominati CapWords.py , questo è ora sconsigliato perché confonde quando il modulo prende il nome da una classe. (" wait - ho scritto import StringIO o da StringIO import StringIO ? ")

Linee guida derivate dai Consigli di Guido inserisci qui la descrizione dell'immagine

C'è un articolo su questo: http: // www .cs.kent.edu / ~ jmaletic / documenti / 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.

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top