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

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

Dito isso, quando você vai além de três ou quatro palavras, ou se você usa inicialismos comoXmlForExample, ele deixa de ser tão legível.

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

Comentários

• +1 por me fazer descobrir o modo de óculos! Acabei de testá-lo em um arquivo de código que usa camelCase e percebi como imediatamente começou a ficar melhor (montagem com muitos rótulos em camelCase).
• Ok, o que é o modo de óculos?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Este é um dos poucos lugares em que sempre escolherei” capacidade de digitação “em vez de legibilidade. CamelCase é apenas mais fácil de digitar, e ser mais legal com meus dedos vence um leve 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.

Comentários

• Não ' não concordo com isso, você escreve o código apenas uma vez, mas tem que lê-lo várias vezes depois

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

Seguir as convenções “culturais” é uma boa escolha. “Cultural”, neste caso, significa convenções estabelecidas na equipe / empresa e eles basicamente carregam as convenções de idioma / plataforma também. Ajuda outras pessoas a ler / usar seu código com facilidade e não requer esforços e tempo adicionais para entender o seu código.

Às vezes, é interessante quebrar as notações aceitas. Um de meus pequenos projetos (em Python) usei underscored_names para funções utilitárias / métodos “protegidos” e methodNames estilo Java para métodos. Minha equipe ficou feliz com ele 🙂

Depende da linguagem de programação.

Eu considero usar o caso em o mesmo barco de usar ou não a notação húngara:

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

Comentários

• @Kevin Cantu: Na verdade, o nome Javascript está em PascalCase em vez de camelCase …
• @Guffa: touch é!
• @Kevin Cantu: em JavaScript: XMLHttpRequest < – Eu odeio esse nome com th a passion.
• hipotéticoReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: Na verdade, a notação húngara quase nunca é usada em C ++, uma vez que C ++ já verifica seus tipos. É ' é mais um artefato histórico do que qualquer outra coisa.

Ambos!

Eu faço muito desenvolvimento no CakePHP e uso CamelCase ou $underscored_vars, da seguinte maneira (mesmo fora dos Projetos CakePHP):

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

Comentários

• têm que concordar com você, tendo o primeiro caractere inferior caso me deixa louco! Eu odeio camelCase com uma paixão.
• Em Java, onde os nomes são tipicamente camelCased, os nomes das classes na verdade começam com uma letra maiúscula. Isso é para distingui-los dos nomes dos métodos.

Eu pessoalmente prefiro underscore_case porque 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, tenho um contra-exemplo para aqueles que dizem ” siga a convenção de sua linguagem e suas bibliotecas “.

No passado, escrevíamos o código C no Windows usando underscore_case e chamamos PascalCase Funções Win32:

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

A distinção visual entre os nomes das nossas funções e os nomes das funções da Microsoft foi uma ajuda e não um obstáculo, pois mostrava claramente quando o código estava indo para o “terreno do sistema”.

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

Eu realmente gosto dos travessões normais de Dylan porque são fáceis de digitar e fáceis -para-ler.

Como

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

Mas acho que como essa linguagem é bastante obscura, isso está fora do tópico. .. 🙁

Comentários

• Também estou cansado de pressionar shift para digitar sublinhados.
• Isso geralmente não é possível para nomes de variáveis, uma vez que " – " geralmente significa menos.

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

Comentários

• bem, ' não é mais fácil porque você lê em algum lugar, é ' mais fácil porque era o primeiro com o qual você trabalhou e principalmente porque está mais acostumado, por exemplo i ' m mais confortável com underscore_case.
• como em i ' li que um estudo foi feito e descobri que é melhor.

Eu uso uma mistura às vezes: module_FunctionName. Todas as funções (não estáticas) em 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_send não mostra uma separação grande o suficiente entre o prefixo e o nome da função. i2cBufferSend se mistura no prefixo demais (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 (sua linguagem, sua arquitetura SW, …), e eu gostaria de salientar que misturar esses estilos pode ser útil.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Comentários

• +1 para as últimas 2 linhas, no entanto, não recomendo que você combine convenções de nomenclatura, você deve ficar com uma ou asoutro.
• Contanto que a convenção seja bem definida (prefixo + sublinhado + PascalCase) …
• Eu gosto de usar sublinhados para separar partes de um nome que têm semanticamente disjuntas finalidades, especialmente se a semelhança em qualquer uma das metades for significativa. Por exemplo, as rotinas Motor1_Start(), Motor2_Start(), Motor1_Stop() e Motor2_Stop() tem uma relação que pode ser menos clara sem os sublinhados.

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

Eu sugeriria que se você precisa usar prefixos para diferenciar conjuntos de variáveis, você deve usar uma linguagem que permite criar namespaces ou objetos ou algo para conter essa informação.

myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 

Da mesma forma, se você precisa diferenciar os tipos, por que não usar uma linguagem que os permita?

var intThingy = 7; // :( int thingy = 7; // :) 

Depois de entender isso, e não estiver usando o nome como meta-dados, você não terá nomes longos o suficiente para importa muito se você prefere aquele pressionamento de tecla extra ou não.

Comentários

• Uma das razões para usar camelCase ou underscore_case é que eu não ' t precisa encontrar a definição dos objetos para discernir o que é.

A princípio, concordo com o dafmetal . É da maior importância que você não misture estilos de programação diferentes. Fazer isso em um mesmo arquivo é o pior que você pode fazer IMHO. Em arquivos diferentes, distrai, mas não é fatal.

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

Você também pode usar convenções de nomenclatura diferentes para se referir a coisas diferentes, tanto quanto você provavelmente usa UPPER_CASE para constantes (isso se aplica apenas a certos é claro), você pode usar this_style para nomes de variáveis locais, enquanto você usa camelCase para variáveis de instância / membro. Isso pode não ser necessário quando você tem coisas como self ou this.

Atualizar

Vejamos um caso em que você tem a plataforma Foo que não recomenda nenhuma convenção de nomenclatura e é a escolha do líder da equipe escolher uma. Você é aquele líder de equipe, por que escolheria camelCase ou 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 há essas guerras religiosas por causa dessas pequenas coisas. Mas, depois de se ajustar a qualquer um deles, as discussões parecem totalmente supérfluas.

Para citar Alex Martelli em um assunto muito semelhante:

Claro, eu fico cansado, em Ruby, de digitar o “fim” bobo no final de cada bloco (ao invés de apenas remover a indentação) – mas então eu evito digitar o igualmente bobo “:” que Python requer no início de cada bloco, de modo que “é quase uma lavagem :-). Outras diferenças de sintaxe, como” @foo “versus” self.foo “, ou a maior importância do caso em Ruby vs Python, são realmente irrelevantes para mim.

Outros, sem dúvida, baseiam suas escolhas de linguagens de programação exatamente nessas questões e geram os debates mais acalorados – mas para mim isso é apenas um exemplo de uma das Leis de Parkinson em ação ( o valor do debate sobre uma questão é inversamente proporcional à real importância da questão ).

Fonte

Se você é o líder da equipe, basta escolher um. Uma vez que um não tem nenhuma vantagem sobre o outro, você pode simplesmente jogar os dados ou escolher o que mais gostar.

Eu li há vários anos que os programadores que não falam inglês como primeira língua tendem a achar o caso de sublinhado mais fácil de entender aquele caso de camelo – mas não consigo encontrar a referência e não tenho ideia se é verdade.

Para linguagens de programação que 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. Descobri que é útil manter para mim mesmo e deve ser fácil de seguir para outra pessoa que esteja lendo o código. Acho que, como outros mencionaram, a consistência é o mais importante. Então, acho meu formato para ser simples de manter, enquanto fornece distinções claras entre os tipos de nomes. Eu poderia imaginar interface_Names_Are_Like_This e Abstract_Classes_Are_Like_This como extensões possíveis, mas parecem ser mais complicadas de seguir e talvez não seja uma distinção tão útil de fazer. > Também achei útil ser estrito e nomear coisas em PascalCase, como um analisador HTML como HtmlParser em vez de HTMLParser HTMLparser. Porque acredito que seja mais fácil lembrar a regra estrita e manter os limites das palavras 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, descobri uso na expansão dessas 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 campos privados estão, por definição, em um namespace diferente das variáveis locais, o que significa que você pode pular o iv0 id = “4iva04″ privado ” Campos. Outros formatos eu vi o 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 devem ser acessados apenas internamente pela classe (e tornando super claro quando “está acontecendo fora da classe object._field_x se destaca).

Se dependesse de mim, eu não faria cumprir ou sugerir o uso de qualquer estilo particular porque, como programadores, deveríamos ser capazes de ler um símbolo IfItIsInCamelCase ou in_underscore_space ou mesmo in_SomeOtherStyle e entender o que isso significa. Ter que gastar um mínimo de tempo analisando o símbolo não é uma grande sobrecarga no grande esquema das coisas.

Agora, o principal argumento para uma convenção, eu acho, é que você sabe de antemão qual é o formato de um nome de função / variável e não precisa procurar – é LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Agora, eu rebateria esse argumento dizendo “Obtenha um IDE que ofereça suporte ao preenchimento automático do estilo intellisense!” (nem sempre é possível).

No final, porém, realmente não importa o estilo que você usa, porque o compilador / interpretador 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.

Comentários

• Eu discordo, a aparência da fonte é importante. Veja " O programador pragmático " ' a teoria das janelas quebradas. A variação da convenção de nomenclatura torna a aparência pior. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Embora eu concorde com o ' janela quebrada ' ideia, não ' não acho que a capitalização de símbolos constitua uma ' janela quebrada '. Certamente é um código desordenado, e meu projeto atual certamente tem muito disso que tento arrumar sempre que posso.
• Concordo. Posso ler todos os três igualmente bem. Não ' não importa. Eu apenas uso o que quer que o arquivo esteja usando, depois o que quer que a linguagem proponha (python) e então o que quer que eu sinta que o projeto será mais bem servido. (Eu costumava programar em gwbasic e era tudo em maiúsculas – os bons e velhos tempos!)

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

Eu tendo a preferir camelCase pelo motivo bobo de que faço a maior parte do meu desenvolvimento em Eclipse (para Java, PHP e JavaScript) e quando eu Ctrl + ← ou Ctrl + → por meio das palavras, ele realmente para nos limites do camelCase.

Ou seja: myIntVariable seria tratado pelo Eclipse como 3 palavras quando Ct rl + ←   → ” através dele.

Sei que é uma peculiaridade estranha, mas prefiro poder editar as palavras do meio em um nome de camelCase.