Qual é a convenção de nomenclatura no Python para nomes de variáveis ​​e funções?


773

Vindo de um plano de fundo em C #, a convenção de nomenclatura para nomes de variáveis ​​e métodos geralmente é camelCase ou PascalCase:

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

No Python, vi o acima, mas também vi sublinhados sendo usados:

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

Existe um estilo de codificação definitivo mais preferível para Python?

Respostas:


867

Consulte Python PEP 8: nomes de funções e variáveis :

Os nomes das funções devem estar em minúsculas, com palavras separadas por sublinhados, conforme necessário, para melhorar a legibilidade.

Os nomes de variáveis ​​seguem a mesma convenção que os nomes de funções.

O mixedCase é permitido apenas em contextos onde esse já é o estilo predominante (por exemplo, threading.py ), para manter a compatibilidade com versões anteriores.


127
PEP = Proposta de aprimoramento do Python.
31711 Peter Mortensen

8
@RickyRobinson Que editor de código com morte cerebral você está usando, que não sabe que o sublinhado continua uma palavra? Muitos gratuitos que fazem. Eu uso o Notepad ++, se um IDE não estiver disponível. Para isso, pode baixar um modelo para edição em python. (Outros podem recomendar transferências ainda mais útil livres.)
ToolmakerSteve

57
Um caso para o estilo sublinhado é que você pode usar melhor as palavras de uma letra. Por exemplo (um tanto bobo), findMeAClasstalvez seja mais feio que find_me_a_class.
heltonbiker

9
Acho que a convenção de nomes de variáveis ​​com todas as letras minúsculas não é adequada na computação científica, onde muitas vezes encontramos constantes conhecidas, tensores etc. que são indicados por letras maiúsculas.
andreasdr

12
@rr PEP8 é um "Guia de Estilo" e se descreve como uma Convenção, NÃO uma Norma. Também explica claramente as razões para nem sempre seguir essas "regras".
O Tahaan

710

O Guia de estilos do Google Python possui a seguinte convenção:

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.

Um esquema de nomeação semelhante deve ser aplicado a um CLASS_CONSTANT_NAME


37
a) Adoro exemplos - obrigado. b) Mistura pouco atraente de CamelCase e sublinhados? Mas: Ser novo para Python e seu modelo de dados mais flexível, eu aposto que há pensamento sólida por trás guia do Google ...
Matthew Cornell

19
A mistura @MatthewCornell não é ruim, desde que você cumpra. Na verdade, facilita a legibilidade se você souber que as funções têm sublinhados e as classes não.
Pithikos

1
@MatthewCornell Eu não assumiria que tem algo a ver com python. O Go realmente aplica padrões arbitrários de beleza e não será compilado se você não aderir, por exemplo, à convenção de chaves. Essencialmente, é uma jogada de dados sobre se alguém realmente teve um pensamento cuidadoso ou apenas realmente amou a maneira como faz as coisas.
Tiro parta

Você consideraria um atributo estático constante um GLOBAL_CONSTANT_NAME? Não é exatamente global, pois está no escopo da classe.
James T.

em seguida, entra property... talvez seja uma questão do que o item está fingindo ser, ao invés do que ele realmente é
joelb

240

David Goodger (em "Code Like a Pythonista" aqui ) descreve as recomendações do PEP 8 da seguinte maneira:

  • joined_lower para funções, métodos, atributos, variáveis

  • joined_lowerou ALL_CAPSpara constantes

  • StudlyCaps para aulas

  • camelCase apenas para estar em conformidade com convenções pré-existentes


3
+1 exemplos visuais. Embora eu não conseguia ver onde PEP8 sugere joined_lowerpara constantes , apenas "todas as letras maiúsculas com sublinhados separando palavras". Curioso também sobre o novo recurso enum .
Bob Stein

1
StudlyCaps for classesé uma ótima regra universal para aulas em quase todos os idiomas. Então por que alguns python built-in classes (tais como datetime.datetimenão seguir essa convenção?
Prahlad Yeri

3
@PrahladYeri: Infelizmente, os unittest.TestCase.assertEqualamigos também não seguem a convenção snake_case. A verdade é que partes da biblioteca padrão do Python foram desenvolvidas antes das convenções se solidificarem, e agora estamos presos a elas.
wchargin

3
O CamelCase é confuso porque algumas pessoas dizem que é "camelCase" (também conhecido como "mixedCase") e outras dizem que é "CamelCase" (também conhecido como "StudlyCaps"). Por exemplo, o PEP menciona "CamelCase" enquanto você menciona "camelCase".
Pro Q

o seu aqui-link está morto, talvez ele deve ser substituído por algo como david.goodger.org/projects/pycon/2007/idiomatic
Lobo

42

Como o Guia de estilo do código Python admite,

As convenções de nomenclatura da biblioteca do Python são um pouco complicadas, portanto nunca conseguiremos isso completamente consistente

Observe que isso se refere apenas à biblioteca padrão do Python . Se eles não conseguem ser tão consistentes, dificilmente há muita esperança de ter uma convenção geralmente aderida a todos os códigos Python, existe?

A partir daí, e a discussão aqui, eu deduzir que é não um pecado horrível se alguém continua usando por exemplo, C # 's (clara e bem estabelecida) do Java ou convenções de nomenclatura para variáveis e funções quando atravessar para Python. Tendo em mente, é claro, que é melhor respeitar o estilo predominante de uma base de código / projeto / equipe. Como o Python Style Guide aponta, a consistência interna é mais importante.

Sinta-se livre para me rejeitar como herege. :-) Como o OP, eu não sou um "Pythonista", ainda não.


32

Existe o PEP 8 , como mostram outras respostas, mas o PEP 8 é apenas o guia de estilo para a biblioteca padrão e é considerado como evangelho nela. Um dos desvios mais freqüentes do PEP 8 para outros trechos de código é a nomeação de variáveis, especificamente para métodos. Não existe um estilo predominante, embora, considerando o volume de código que usa mixedCase, se alguém fizesse um censo estrito, provavelmente terminaria com uma versão do PEP 8 com mixedCase. Há pouco outro desvio do PEP 8 que é tão comum.


9
Isso pode ter sido verdade em 08 quando isso foi respondido, mas hoje em dia quase todas as principais bibliotecas usam convenções de nomenclatura do PEP 8.
Thane Brimhall

29

Como mencionado, o PEP 8 diz para usar lower_case_with_underscorespara variáveis, métodos e funções.

Prefiro usar lower_case_with_underscorespara variáveis ​​e mixedCasemétodos e funções para tornar o código mais explícito e legível. Assim, seguindo o Zen do Python, "explícito é melhor que implícito" e "Legibilidade conta"


3
+1 Eu troco esses dois (eu uso mixedCase para variáveis), mas ter tudo mais distinto assim ajuda a tornar imediatamente óbvio o que você está lidando, especialmente porque você pode repassar funções.
Xiong Chiamiov 12/07/2009

2
Embora a "legibilidade" seja altamente subjetiva. Acho métodos com sublinhado mais legíveis.
Pithikos

Sua preferência foi minha intuição inicial, decorrente de muitos anos de desenvolvimento Java. Eu gosto de usar _ para variáveis, mas a partir dos olhos, me parece um pouco engraçado para funções e métodos.
Michael Szczepaniak

21

além do que @JohnTESlade respondeu. O guia de estilo python do Google tem algumas recomendações bem legais,

Nomes a evitar

  • nomes de caracteres únicos, exceto contadores ou iteradores
  • traços (-) em qualquer nome de pacote / módulo
  • \__double_leading_and_trailing_underscore__ names (reservado por Python)

Convenção de nomes

  • "Interno" significa interno de um módulo ou protegido ou privado dentro de uma classe.
  • A adição de um único sublinhado (_) tem algum suporte para proteger variáveis ​​e funções do módulo (não incluídas na importação * de). A adição antecipada de um sublinhado duplo (__) a uma variável ou método de instância serve efetivamente para tornar a variável ou o método privado para sua classe (usando a manipulação de nome).
  • Coloque classes relacionadas e funções de nível superior juntas em um módulo. Ao contrário do Java, não há necessidade de se limitar a uma classe por módulo.
  • Use CapWordspara nomes de classes, mas lower_with_under.pypara nomes de módulos. Embora existam muitos módulos nomeados CapWords.py, isso agora é desencorajado porque é confuso quando o módulo recebe o nome de uma classe. ("espera - eu escrevi import StringIOou from StringIO import StringIO?")

Diretrizes derivadas das recomendações de Guido insira a descrição da imagem aqui


17

A maioria das pessoas python prefere sublinhados, mas mesmo que eu esteja usando python há mais de 5 anos, ainda não gosto deles. Eles só parecem feios para mim, mas talvez isso seja todo o Java na minha cabeça.

Eu simplesmente gosto mais do CamelCase, pois ele se encaixa melhor na maneira como as classes são nomeadas. Parece mais lógico SomeClass.doSomething()que isso SomeClass.do_something(). Se você procurar no índice global do módulo em python, encontrará os dois, devido ao fato de ser uma coleção de bibliotecas de várias fontes que aumentaram horas extras e não algo que foi desenvolvido por uma empresa como a Sun com regras estritas de codificação . Eu diria que o essencial é: use o que quiser melhor, é apenas uma questão de gosto pessoal.


10
Eu sou proveniente de Java e acho sublinhados detalhados e pouco atraentes, com apenas o último sendo opinião. Nomear é, em alguns aspectos, um equilíbrio entre legibilidade e brevidade. O Unix vai longe demais, mas o idioma en.wikipedia.org/wiki/Domain-specific_language é limitado. O CamelCase é legível devido às tampas, mas não possui caracteres extras. 2c
Matthew Cornell

2
Para mim, os sublinhados são atraentes em funções / métodos, pois vejo cada sublinhado como um separador para um espaço de nome virtual (na minha cabeça). Dessa forma eu posso facilmente saber como nomear minhas novas funções / métodos: make_xpath_predicate, make_xpath_expr, make_html_header,make_html_footer
Pithikos

3
Você não chama (normalmente) SomeClass.doSomething()(os métodos estáticos são geralmente raros) que você costuma chamar #an_instance.do_something()
Dave

15

Pessoalmente, tento usar o CamelCase para classes, métodos e funções mixedCase. As variáveis ​​geralmente são separadas por sublinhado (quando me lembro). Dessa forma, posso dizer rapidamente o que exatamente estou chamando, em vez de tudo parecer o mesmo.


15
A caixa de camelo começa com uma letra minúscula IIRC como "camelCase".
UnkwnTech

11
Acho que a crystalattice estava certa - pelo menos, seu uso é consistente com o uso no PEP8 (CamelCase e mixedCase).
Jarrett

1
@UnkwnTech O termo para FirstLetterUpper às vezes é chamado de PascalCase
SurpriseDog

CamelCase ou camelCase? apenas me perguntando.
Sumit Pokhrel 22/01

11

Há um artigo sobre isso: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Diz que snake_case é mais legível que camelCase. É por isso que as línguas modernas usam (ou deveriam usar) cobra sempre que podem.


9
Curiosamente, ele também diz: "Os resultados deste estudo podem não se aplicar necessariamente a identificadores incorporados no código-fonte. É inteiramente possível que identificadores em camelo possam agir como um melhor elemento de gestalt quando incorporados em construções de programação".
rob3c

2

O estilo de codificação geralmente faz parte dos padrões de política / convenção internos de uma organização, mas acho que, em geral, o estilo all_lower_case_underscore_separator (também chamado snake_case) é mais comum em python.


0

Pessoalmente, uso as convenções de nomenclatura do Java ao desenvolver em outras linguagens de programação, pois é consistente e fácil de seguir. Dessa forma, não estou lutando continuamente sobre quais convenções usar e que não devem ser a parte mais difícil do meu projeto!


Eu concordo um pouco. Se o idioma X for apenas uma pequena quantidade do projeto, a mudança de contexto de como formatar o texto pode ser um fardo. O principal problema é que as bibliotecas terão chamadas em um estilo ( library_function(my_arg)).
Lan

-2

Normalmente, segue-se as convenções usadas na biblioteca padrão do idioma.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.