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
Respostas:
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:
ou isto:
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):Acho esta versão muito mais fácil de ler:
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.
fonte
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 =)
fonte
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.
fonte
Com base em uma resposta, a resposta de John Isaacks:
Eu decidi fazer uma pesquisa e encontrei este artigo . O que a ciência tem a dizer sobre o assunto?
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. :)
fonte
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".
fonte
if (...) {
economizando uma linha! Hoje em dia, há mais espaço na tela - a K&R seria diferente se hoje fosse escrita com IDEs de GUI de alta resolução e várias configurações de monitores?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.
fonte
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.
fonte
É 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_names
para funções utilitárias / métodos "protegidos" e estilo JavamethodNames
para métodos. Minha equipe ficou feliz com isso :)fonte
Depende da linguagem de programação.
Considero usar o caso no mesmo barco para usar ou não a notação húngara:
fonte
XMLHttpRequest
<- Eu odeio esse nome com paixão.Ambos!
Eu desenvolvo bastante o CakePHP e uso um
CamelCase
ou outro$underscored_vars
, da seguinte maneira (mesmo fora dos Projetos CakePHP):/lowercased_underscored.php
Típico, mas vale a pena mencionar.class CamelCase extends ParentObject
. Observe que, ao usarCamelCase
, o caractere inicial não é minúsculo. Eu achocamelCase
que olhar realmente estranho.$are_variables_underscored === TRUE;
$CamelCase = new CamelCase();
$collection['underscored_keys'];
ALL_CAPS_AND_UNDERSCORED
.$CamelCase->foo_method_underscored();
CamelCase::just_like_regular_methods();
fonte
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, 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_case
e denominamosPascalCase
funções Win32: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).
fonte
Eu realmente gosto dos traços normais de Dylan, pois eles são fáceis de digitar e fáceis de ler.
Gostar
Mas acho que, como essa linguagem é bastante obscura, isso é meio fora de tópico ... :(
fonte
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.
fonte
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á.
fonte
À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:
A alternativa
i2c_buffer_send
não mostra uma separação grande o suficiente entre prefixo e nome da função.i2cBufferSend
mistura 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.
fonte
Motor1_Start()
,Motor2_Start()
,Motor1_Stop()
eMotor2_Stop()
têm uma relação que pode ser menos claro, sem os sublinhados.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.
Da mesma forma, se você precisar diferenciar tipos, por que não usar um idioma que permita isso?
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.
fonte
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
self
outhis
no entanto.Atualizar
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:
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.
fonte
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.
fonte
Para linguagens de programação que eu usei, como Java, Python, C ++, adotei um formato claro:
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 classeobject._field_x
).fonte
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:
Três estilos diferentes, mas você sabe exatamente o que cada um faz.
fonte
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.
fonte
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:
myIntVariable
seriam 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.
fonte