Convenções de nomenclatura: camelCase versus underscore_case? Quais são seus pensamentos sobre isso? [fechadas]

Uso o underscore_case há cerca de 2 anos e mudei recentemente para o camelCase por causa do novo trabalho (uso o mais recente há cerca de 2 meses e ainda acho que o underscore_case é mais adequado para grandes projetos em que há muitos programadores envolvidos, principalmente porque o código é mais fácil de ler).

Agora, todo mundo no trabalho usa o camelCase porque (como eles dizem) o código parece mais elegante.

O que você pensa sobre camelCase ou underscore_case

ps desculpe meu inglês ruim

Editar

Alguma atualização primeiro:

• A plataforma usada é PHP (mas não estou esperando respostas estritas relacionadas à plataforma PHP, qualquer pessoa pode compartilhar seus pensamentos sobre qual seria o melhor para usar, por isso vim aqui em primeiro lugar)

• Eu uso o camelCase como todos os outros membros da equipe (assim como a maioria de vocês recomenda)

• usamos o Zend Framework, que também recomenda o camelCase

Alguns exemplos (relacionados ao PHP):

• A estrutura do Codeigniter recomenda underscore_case e, honestamente, o código é mais fácil de ler.

• A ZF recomenda o camelCase e eu não sou o único que acha que o código ZF é um pouco mais difícil de seguir.

Então, minha pergunta seria reformulada:

Vamos considerar um caso em que você tem a plataforma Foo, que não recomenda convenções de nomenclatura e a escolha do líder da equipe é escolher uma. Você é o líder da equipe, por que escolheria camelCase ou por que underscore_case?

ps obrigado a todos pelas respostas rápidas até agora

Concordo que isso depende do idioma que você está usando até certo ponto; o código tende a parecer mais limpo quando os nomes dos seus símbolos seguem o mesmo regime de formatação que as bibliotecas incorporadas e de estoque do idioma.

Mas onde há uma escolha, prefiro sublinhados a estojo de camelo, por uma simples razão: acho esse estilo mais fácil de ler. Aqui está um exemplo: qual você acha mais legível? Este:

aRatherLongSymbolName

ou isto:

a_rather_long_symbol_name

Acho a versão sublinhada muito mais fácil de ler. Meu cérebro pode ignorar os sublinhados muito mais facilmente do que ele pode detectar os limites das maiúsculas / minúsculas no caso de camelo, especialmente onde estão os limites entre glifos que se assemelham a outros glifos do caso oposto, ou numerais ( I/l, O/0, t/I, etc). Por exemplo, essa variável booleana armazena um valor indicando se um iglu foi ou não construído com a devida permissão de planejamento (sem dúvida, um caso de uso comum para todos nós):

isIllicitIgloo

Acho esta versão muito mais fácil de ler:

is_illicit_igloo

Talvez ainda pior do que o nome de um símbolo de difícil leitura seja um nome de símbolo de fácil leitura. Os bons nomes de símbolos são auto-documentados, o que para mim significa que você deve poder lê-los e entender rapidamente o significado deles. (Tenho certeza de que todos lemos impressões de códigos na cama por prazer, mas ocasionalmente também ficamos com pressa.) Costumo encontrar com nomes de símbolos de camelo que é fácil lê-los erroneamente e ter a impressão errada de que um semântica do símbolo.

Eu acho que você deve usar a convenção de nomenclatura adotada por sua plataforma. underscore_case ficará estranho no código C #, como camelCase no Ruby =)

Honestamente, isso realmente não importa, desde que todos na equipe usem o mesmo esquema. As chances são de que uma ou outra seja mais natural para você, embora a real importância seja a legibilidade do código a longo prazo e, em seguida, é crucial que todos sigam as mesmas regras de nomenclatura.

Com base em uma resposta, a resposta de John Isaacks:

"honestamente, o código é mais fácil de ler" Opinião ou fato?

Eu decidi fazer uma pesquisa e encontrei este artigo . O que a ciência tem a dizer sobre o assunto?

1. O revestimento de camelo tem uma maior probabilidade de correção do que os sublinhados. (as probabilidades são 51.5% mais altas)
2. Em média, a caixa de camelo levou 0,42 segundos a mais , o que é 13,5% a mais.
3. O treinamento não tem impacto estatisticamente significativo sobre como o estilo influencia a correção.
4. Aqueles com mais treinamento foram mais rápidos em identificadores no estilo camel case.
5. O treinamento em um estilo afeta negativamente a hora de encontrar outros estilos.

No meu blog sobre o assunto, reviso o artigo científico e faço a seguinte conclusão.

Somente a lentidão do caso camel (2) é realmente relevante para a programação, descartando os outros pontos como irrelevantes devido aos IDEs modernos e à maioria dos usuários camelCase no estudo. A discussão (junto com uma enquete) pode ser encontrada na postagem do blog.

Estou curioso para saber como este artigo pode mudar sua opinião. :)

Copie os caras mais inteligentes

No caso de linguagens de programação, copie o estilo do desenvolvedor da linguagem.

Por exemplo, eu codifico C exatamente como é feito em K&R.

Então, quando alguém tenta iniciar uma conversa chata no estilo de codificação, posso dizer a eles "conversem com Dennis Ritche e me digam o que ele diz".

Em geral, eu prefiro o camelCase. No entanto, isso ocorre porque, durante a maior parte da minha carreira, trabalho em idiomas e ambientes em que os guias de estilo normalmente recomendam o camelCase. (Java, ECMAScript, C ++). Você, sendo uma pessoa PHP, provavelmente terá a preferência oposta.

Dito isto, quando você ultrapassa trêsOrFourWords ou se usa inicialismos como XmlForExample, ele deixa de ser tão legível.

É por isso que o emacs nos dá o modo de óculos.

camelCase

Este é um dos poucos lugares em que sempre escolherei 'capacidade de digitação' em vez de legibilidade. O CamelCase é apenas mais fácil de digitar, e ser mais agradável aos meus dedos vence um pequeno ganho de legibilidade para mim.

assumindo, é claro, que o projeto não se baseia em uma base de código existente com um padrão diferente.

É uma pergunta interessante, já pensei nisso muitas vezes. Mas não há uma resposta definitiva, eu acho.

Seguindo as convenções "culturais", é uma boa escolha. "Cultural", neste caso, significa convenções estabelecidas na equipe / empresa e, basicamente, elas também possuem as convenções de idioma / plataforma. Ajuda outras pessoas a ler / usar seu código facilmente e não exige esforços e tempo adicionais para entender o seu código.

Às vezes, é interessante quebrar as notações aceitas. Um dos meus pequenos projetos (no Python) que usei underscored_namespara funções utilitárias / métodos "protegidos" e estilo Java methodNamespara métodos. Minha equipe ficou feliz com isso :)

Depende da linguagem de programação.

Considero usar o caso no mesmo barco para usar ou não a notação húngara:

• Python: underscore_case, sem notação húngara
• C ++: camelCase, notação húngara

Ambos!

Eu desenvolvo bastante o CakePHP e uso um CamelCaseou outro $underscored_vars, da seguinte maneira (mesmo fora dos Projetos CakePHP):

1. nomes de arquivos - /lowercased_underscored.phpTípico, mas vale a pena mencionar.
2. classes - class CamelCase extends ParentObject. Observe que, ao usar CamelCase, o caractere inicial não é minúsculo. Eu acho camelCaseque olhar realmente estranho.
3. variáveis -$are_variables_underscored === TRUE;
4. variáveis ​​que mantêm instâncias -$CamelCase = new CamelCase();
5. chaves de matriz -$collection['underscored_keys'];
6. constantes - Eu acho que todos podem concordar que constantes devem ser ALL_CAPS_AND_UNDERSCORED.
7. métodos -$CamelCase->foo_method_underscored();
8. métodos estáticos -CamelCase::just_like_regular_methods();

Pessoalmente, prefiro underscore_caseporque acho mais legível, mas concordo com os outros respondentes que apontam que a consistência com a base de código existente é muito mais importante.

No entanto, eu tenho um contra-exemplo para quem diz "siga a convenção do seu idioma e de suas bibliotecas".

No passado, escrevemos o código C no Windows usando underscore_casee denominamos PascalCasefunções Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

A distinção visual entre os nomes de nossas funções e os nomes de funções da Microsoft foi mais uma ajuda do que um obstáculo, como mostrou claramente quando o código estava entrando na "área do sistema".

Além disso, consegui alterar as regras de destaque da sintaxe do meu editor para exibi-las em cores diferentes, o que deu mais pistas visuais ao tentar entender seções desconhecidas do código (ou até as minhas).

Eu realmente gosto dos traços normais de Dylan, pois eles são fáceis de digitar e fáceis de ler.

Gostar

result-code := write-buffer(file-stream, some-string)

Mas acho que, como essa linguagem é bastante obscura, isso é meio fora de tópico ... :(

Fui ensinado a usar o camelCase na universidade. Eu usei algumas convenções diferentes nos últimos anos, mas prefiro o camelCase a qualquer outra coisa. Acho que lembro de ler em algum lugar que o camelCase é realmente o mais fácil de ler e entender.

Como a maioria das pessoas mencionou - Use o padrão existente. Se for um novo projeto, use o padrão para o idioma e as estruturas que você usará.

E não se confunda, não se trata de legibilidade (que é subjetiva), é ser consistente e profissional. Qualquer um que tenha trabalhado em uma base de código com vários "padrões" em andamento entenderá.

Às vezes, uso um mix: module_FunctionName. Todas as funções (não estáticas) dos meus módulos começam com uma abreviação de módulo.

Por exemplo, uma função para enviar o conteúdo de um buffer no barramento I2C:

i2c_BufferSend()

A alternativa i2c_buffer_sendnão mostra uma separação grande o suficiente entre prefixo e nome da função. i2cBufferSendmistura demais o prefixo (há várias funções I2C neste módulo).

i2c_Buffer_send pode ter sido uma alternativa, no entanto.

Minha resposta é que você se adapta ao que funciona melhor para o seu projeto (seu idioma, sua arquitetura de SW, ...), e eu queria ressaltar que a mistura desses estilos pode ser útil.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Eu_respeito_a_fato_que_alguma_pode_para_pensar_do_externo_but_I_do_not_really_understand_why.

Pessoalmente, prefiro o camelCase, mas em algumas fontes acho que os sublinhados são mais fáceis de ler.

Sugiro que se você precisar usar prefixos para diferenciar conjuntos de variáveis, use uma linguagem que permita criar espaços para nome ou objetos ou algo para armazenar essas informações.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Da mesma forma, se você precisar diferenciar tipos, por que não usar um idioma que permita isso?

var intThingy = 7; // :(

int thingy = 7;    // :)

Depois de entender isso direito e não usar apenas o nome como meta-dados, você não terá nomes longos suficientes para que importe muito se você prefere pressionar ou não a tecla extra.

No começo, eu concordo com dafmetal. É da maior importância que você não misture diferentes estilos de programação. Fazer isso em um único arquivo é o pior que você pode fazer no IMHO. Em arquivos diferentes, é perturbador, mas não fatal.

A próxima coisa que você precisa fazer é nomear regras que são populares para a linguagem em que você está escrevendo. Meu código C ++ para instnace terá uma aparência diferente de algo para Python, obviamente (o PEP8 é um bom guia aqui)

Você também pode usar convenções de nomenclatura diferentes para se referir a coisas diferentes, por mais que você provavelmente use UPPER_CASE para constantes (isso se aplica apenas a certos idiomas, é claro), você pode usar esse estilo para nomes de variáveis ​​locais, enquanto usa camelCase por exemplo / membro variáveis. Isso pode não ser necessário quando você tem coisas como selfou thisno entanto.

Atualizar

Vamos considerar um caso em que a plataforma Foo Witch não recomenda nenhuma convenção de nomenclatura e a escolha do líder da equipe é escolher uma. Você é o líder da equipe, por que escolheria camelCase ou por que underscore_case.

Na verdade, não há vantagens para um sobre o outro. Este assunto é muito subjetivo e, uma vez acordado, não fará diferença. Sempre existem essas guerras religiosas sobre essas pequenas coisas. Mas uma vez que você se ajustou a qualquer um deles, as discussões parecem ser inteiramente supérfluas.

Para citar Alex Martelli sobre um assunto muito semelhante:

Claro, em Ruby, eu me canso de digitar o "final" bobo no final de cada bloco (em vez de apenas desinteressante) - mas evito digitar o igualmente: "bobo": o que o Python exige em o início de cada bloco, então isso é quase uma lavagem :-). Outras diferenças de sintaxe como '@foo' versus 'self.foo', ou o significado mais alto de maiúsculas e minúsculas em Ruby vs Python, são realmente tão irrelevantes para mim.

Outros, sem dúvida, baseiam sua escolha de linguagens de programação nessas questões e geram os debates mais quentes - mas para mim esse é apenas um exemplo de uma das Leis de Parkinson em ação ( o valor do debate sobre um assunto é inversamente proporcional ao da questão). importância real ).

Fonte

Se você é o líder da equipe, basta ir com um. Como um não tem vantagens sobre o outro, você pode simplesmente jogar dados ou escolher o que mais gosta.

Li vários anos atrás que os programadores que não falam inglês como primeira língua tendem a achar o caso sublinhado mais fácil de entender esse caso de camelo - mas não consigo encontrar a referência e não tenho idéia se é verdade.

Para linguagens de programação que eu usei, como Java, Python, C ++, adotei um formato claro:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Isso me permite discernir imediatamente com o que estou lidando. Eu descobri que isso é útil para manter para mim, e deve ser fácil de seguir para outra pessoa que está lendo o código. Acho que, como outros mencionaram, a consistência é mais importante. Portanto, acho que meu formato é simples o suficiente para manter, fornecendo distinções claras entre tipos de nomes. Eu poderia imaginar interface_Names_Are_Like_This e Abstract_Classes_Are_Like_This como possíveis extensões, mas parece ser mais complicado de seguir e talvez não seja tão útil uma distinção a ser feita.

Também achei útil ser rigoroso e nomear coisas no PascalCase, como um analisador de HTML como HtmlParser, em vez de HTMLParser ou HTMLparser. Porque acredito que é mais fácil lembrar-se da regra estrita e manter os limites da palavra mais claros (infelizmente, isso requer erros de ortografia, como HTML ou SQL). Da mesma forma com camelCase, htmlParserMethod em vez de HTMLParserMethod ou HTMLparserMethod.

ATUALIZAÇÃO :

Desde então, achei útil expandir essas regras para incluir variáveis ​​privadas. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Em Java, isso significa que os campos privados estão, por definição, em um espaço de nome diferente das variáveis ​​locais, o que significa que você pode pular os this.campos particulares. Outros formatos que eu já vi prefixo com " m", mas esses formatos também usam camelCase para os nomes das variáveis. Isso também me permite fazer uma distinção entre campos que só devem ser acessados ​​internamente pela classe (e ficar super claro quando isso acontece fora da classe object._field_x).

Se dependesse de mim, eu não aplicaria ou sugeriria o uso de um estilo específico, porque, como programadores, poderíamos ler um símbolo IfItIsInCamelCase ou in_underscore_space ou mesmo em_SomeOtherStyle e entender o que isso significa. Ter que gastar um pouco de tempo analisando o símbolo não é uma grande sobrecarga no grande esquema das coisas.

Agora, acho que o principal argumento para uma convenção é que você sabe qual é o formato de um nome de função / variável e não precisa procurá-lo - é LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Agora, eu iria contra esse argumento dizendo "Obtenha um IDE que suporte a conclusão automática do estilo intellisense!" (nem sempre é possível).

No final, porém, não importa realmente o estilo que você usa, porque o compilador / intérprete não se importa. O importante é que o nome seja útil:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Três estilos diferentes, mas você sabe exatamente o que cada um faz.

Pode parecer bobagem, mas não gosto de sublinhados porque o sublinhado é fino e oculta em texto de várias linhas e sinto falta dele. Além disso, em alguns (muitos) editores de texto e / ou ambientes de desenvolvimento, quando você clica duas vezes no nome de um token para destacá-lo, de modo a copiá-lo ou arrastá-lo e soltá-lo, o sistema não destacará o token inteiro, destacando apenas uma parte do token, entre sublinhados adjacentes. Isso me deixa louco.

Eu tendem a preferir o camelCase pela razão boba de que faço a maior parte do meu desenvolvimento no Eclipse (para Java, PHP e JavaScript) e, quando eu Ctrl+ ←ou Ctrl+ →por meio de palavras, ele para nos limites do camelCase.

Ie: myIntVariableseriam tratados por Eclipse como 3 palavras quando Ctrl+ ← →'ing através dele.

Eu sei que é uma peculiaridade estranha, mas me pego preferindo editar as palavras do meio em um nome camelCase.