Qual é a convenção de nomenclatura em Python para nomes de variáveis ??e função?

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

Pergunta

Vindo de um fundo C # A convenção de nomenclatura para variáveis ??e nomes de métodos são geralmente quer CamelCase ou Pascal caso: 

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

Em Python, eu vi o acima, mas também tenho visto sublinhados sendo utilizado: 

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

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

Foi útil?

Solução

Veja Python PEP 8 .

Nomes de funções devem estar em letras minúsculas, com palavras separadas por sublinhados como necessário para melhorar a legibilidade.

MixedCase é permitido apenas em contextos onde isso é já o predominante estilo

Variáveis ??...

Use as regras função de nomeação: minúsculas com palavras separadas por sublinhados como necessárias para melhorar legibilidade.

Pessoalmente, eu desviar-se isso porque eu também preferem mixedCase sobre lower_case para meus próprios projetos.

Outras dicas

Guia de Estilo Python Google tem 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 nomenclatura semelhante deve ser aplicada a um CLASS_CONSTANT_NAME

David Goodger (em "O código gosta de uma Pythonista" aqui ) descreve o PEP 8 recomendações da seguinte forma:

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

  • joined_lower ou ALL_CAPS para constantes

  • StudlyCaps para as classes

  • camelCase só para estar de acordo com convenções pré-existentes

Como href="http://www.python.org/dev/peps/pep-0008/" Guia estilo para admite Código Python,

As convenções de nomenclatura de Python biblioteca são um pouco de uma confusão, por isso vamos nunca se esta completamente consistente

Note que isto se refere apenas para Python do biblioteca padrão . Se eles não podem obter que consistente, então não há mal há muita esperança de ter um modo geral aderida-a convenção para todas código Python, não é?

A partir daí, e a discussão aqui, eu deduzir que não um pecado horrível de se mantém usando, por exemplo Java de ou C # 's (clara e bem estabelecida) convenções de nomenclatura para variáveis ??e funções quando atravessar para Python. Tendo em mente, é claro, que o melhor é permanecer com qualquer que seja o estilo prevalecente para uma base de código / projecto / equipa passa a ser. Como Guia de Estilo do Python aponta, consistência interna é mais importante.

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

Há PEP 8 , como outras respostas mostram, mas PEP 8 é apenas o Styleguide para a biblioteca padrão, e isso só é tomado como um evangelho nele. Uma das mais frequentes desvios de PEP 8 para outras peças de código é a nomenclatura de variáveis, especificamente para métodos. Não existe um estilo predominante única, embora considerando o volume de código que usa MixedCase, se alguém fosse fazer uma estrita um censo provavelmente iria acabar com uma versão do PEP 8 com MixedCase. Há pouco outro desvio do PEP 8, que é tão comum.

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

Eu prefiro usar lower_case_with_underscores para variáveis ??e mixedCase para métodos e funções torna o código mais explícito e legível. Assim, seguindo o Zen de do Python "explícito é melhor do que implícito" e "legibilidade conta "

Pessoalmente eu tento usar CamelCase para classes, métodos e funções MixedCase. As variáveis ??são geralmente sublinhado separados (quando eu me lembro). Dessa forma eu posso dizer em poucas palavras o que exatamente eu estou chamando, em vez de tudo com a mesma aparência.

A maioria das pessoas preferem python sublinhados, mas mesmo que eu estou usando python há mais de 5 anos agora, eu ainda não gosto deles. Eles basta olhar feio para mim, mas talvez isso é tudo o Java na minha cabeça.

Eu simplesmente como CamelCase melhor desde que ele se encaixa melhor com a forma como as classes são nomeadas, parece mais lógico ter SomeClass.doSomething() que SomeClass.do_something(). Se você olhar em volta no índice módulo global em python, você vai encontrar ambos, que é devido ao fato de que é uma coleção de bibliotecas de várias fontes que cresceram horas extras e não algo que foi desenvolvido por uma empresa como a Sun com regras de codificação rigorosas . Eu diria que a linha de fundo é:. Use o que você gosta mais, é apenas uma questão de gosto pessoal

também em que @JohnTESlade respondeu. guia de estilo python do Google tem algumas recomendações bastante puro,

Nomes para evitar

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

Naming Convention

  • meios "interno" internos para um módulo ou protegidos ou privados dentro de uma classe.
  • Prepending um único sublinhado (_) tem algum suporte para proteger variáveis ??e funções do módulo (não incluído com importação * from). Prepending um sublinhado duplo (__) para uma variável de instância ou método efetivamente serve para fazer a variável ou método particular para sua classe (usando desconfiguração do nome).
  • aulas Lugar relacionados e funções de nível superior em conjunto em um módulo. Ao contrário de Java, não há necessidade de limitar-se a uma aula por módulo.
  • Use CapWords para nomes de classes, mas lower_with_under.py para os nomes dos módulos. Embora existam muitos módulos existentes nomeados CapWords.py, isto agora é desencorajado porque está confuso quando o módulo passa a ser chamado depois de uma aula. ( "Espera? - eu escrever import StringIO ou from StringIO import StringIO")

Diretrizes derivado de Recomendações de Guido enter descrição da imagem aqui

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

TL; DR Ele diz que snake_case é mais legível do que camelCase. É por isso que as línguas modernas usam (ou deveria usar) cobra onde é possível.

O estilo de codificação é normalmente parte de padrões de política / convenções internas 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.

Normalmente, um seguir as convenções usadas na biblioteca padrão da linguagem.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top