Qual é o motivo do uso de letras minúsculas para a primeira palavra em uma variável local (por exemplo, employeeCount, firstName)

20

Eu recebo muitas críticas de outros programadores devido ao meu uso de case completo e adequado para todas as minhas variáveis. Por exemplo, seu programador típico usará employeeCountpara um nome de variável, mas eu uso EmployeeCount. Uso maiúsculas e minúsculas para tudo , seja um método nulo, método de retorno, variável, propriedade ou constante. Eu até sigo esta convenção em Javascript. Esse último realmente mexe com os impulsos das pessoas.

A razão típica dada por que eu não devo seguir esta convenção de caixa "não-padrão" é porque o caso completo deve ser reservado para propriedades e métodos nulos. A variável local e os métodos que retornam um valor devem ter a primeira palavra em minúsculas int employeeCount = getEmployeeCount().

No entanto, eu não entendo o porquê.

Quando questiono isso, parece que recebo uma resposta arbitrária desse padrão . Seja qual for a resposta, geralmente sempre se resume a: É assim que as coisas são e eu não questiono. Eu apenas sigo. . Respostas arbitrárias nunca são boas o suficiente para mim.

Desde meus primeiros dias de programação de macros do Excel 97 com o Office IDE, nunca precisei de uma convenção de caso para me dizer se algo é ou não uma variável ou propriedade local. Isso ocorre porque eu sempre usei uma convenção de nomenclatura muito intuitiva. Por exemplo, GetNuggetCount()sugere claramente um método que vai a algum lugar e obtém uma contagem de todas as pepitas. SetNuggetCount(x)sugere que você esteja atribuindo um novo valor à contagem de pepitas. NuggetCountpor si só sugere uma propriedade ou variável local que está simplesmente mantendo um valor. Nesse último, podemos ficar tentados a dizer: "Ah, ah! Essa é a pergunta. Propriedade ou variável? QUAL É?" Para isso, eu respondia: "Isso realmente importa?"

Então, aqui está o tl; dr ;: Quais são os motivos objetivos, lógicos e não arbitrários para usar letras minúsculas para a primeira palavra em sua variável ou método de retorno?

Edit: Para MainMa

Substitua esse código pelo primeiro exemplo de código em sua resposta e veja como seu argumento se mantém:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}
oscilatingcretin
fonte
7
Se eles estavam em maiúsculas haveria alguém perguntar por que eles não estão em letras minúsculas ...
m3th0dman
11
não seria legal se nossos IDEs poderosos pudessem ter um plug-in que mapeou nossas próprias preferências pessoais para questões estilísticas como essa e nos permitiu usá-las, mas nos bastidores, para a "versão real" do arquivo de origem, aplicada semântica de estilo do "projeto". É uma questão totalmente visual até que você precise auditar a versão oficial do arquivo. apenas sonhando ...
Sassafras_wot
59
Infelizmente para você, o motivo real e válido é "porque é o padrão". Vale a pena que as pessoas da mesma equipe sigam o mesmo padrão de estilo de código. Se você não conseguir entender o porquê, talvez faça outra pergunta: "por que os padrões são úteis?"
Andres F.
3
Eu sempre assumi que os desenvolvedores optaram pelo camelCase porque ele parecia torto. Não há razão 'objetiva' para o próprio camelCase acima do PascalCase. Pessoalmente, acho o PascalCase (como o seu exemplo) muito mais fácil de ler e o uso na maioria dos lugares que não sejam o JavaScript, onde mantenho o camelCase para não perder convites para festas.
precisa
7
Pesquisa sobre as vantagens de ter um estilo de codificação padrão Realmente não importa qual é o padrão, apenas que ele é seguido.
Mr.Mindor

Respostas:

88

Essa convenção de nomenclatura é frequentemente usada quando as pessoas desejam poder atribuir a uma variável o mesmo nome que seu tipo. Por exemplo:

Employee employee;

Alguns idiomas até reforçam essa capitalização. Isto evita ter que usar nomes de variáveis irritantes como MyEmployee, CurrentEmployee, EmployeeVar, etc. Você sempre pode dizer se algo é um tipo ou uma variável, apenas de capitalização. Isso evita confusão em situações como:

employee.function(); // instance method
Employee.function(); // static method

Além disso, em inglês, os substantivos geralmente não estão em maiúsculas, portanto você não pode realmente afirmar que sua capitalização é "adequada".

Então, o que isso tem a ver com a sua situação? Obviamente, você não tem problemas para ler seu próprio código, mas, ao manter as coisas o mais consistente possível, reduz a carga de trabalho mental de qualquer outra pessoa que precise ler seu código. Na codificação e na escrita, você ajusta seu estilo para combinar com os leitores.

Karl Bielefeldt
fonte
1
Observe que o problema ainda existe no idioma usado pelo OP, pois as propriedades são maiúsculas (é claro, as propriedades podem ser prefixadas por this., o que evita a confusão; as variáveis ​​locais não podem ter esse prefixo).
Arseni Mourzenko
1
@oscilatingcretin é chamado PascalCase.
Mr.Mindor
21
Employee Employeefunciona, mas vou argumentar que é mais confuso para um leitor humano do que Employee employee. Este último parece duas coisas diferentes. O primeiro parece repetição desnecessária.
Jamie F
14
@oscilatingcretin Exatamente: "assume que o leitor entende a estrutura subjacente ..." Eu gosto de ler JavaScript, Java, C #, C ++ e outros e traduzir o código na minha cabeça. Não gosto de continuar pensando "Ah, o compilador dessa linguagem pode lidar com x ". enquanto estou apenas tentando entender o significado do código.
Jamie F
1
Observe que employee.function()também pode ser um método estático, se a linguagem permitir chamar métodos estáticos de um objeto (como o Java faz). O compilador emite um aviso, mas é permitido fazer isso.
Uooo
34

Não existe. É o que a maioria das pessoas faz, por isso se tornou o padrão, porque é isso que todos fazem. Muita literatura segue essa convenção para que as pessoas adquiram o hábito.

A convenção não é tão importante quanto a consistência no código. Desde que tudo seja nomeado de maneira consistente, para que eu saiba o que as coisas estão olhando para eles, não importa realmente se a primeira letra é maiúscula ou não.

Eu achava chocante encontrar um código escrito da sua maneira e diria que eu não gosto. Mas isso é uma questão de estilo.

Agora, se você estiver fazendo isso no local de trabalho, seria melhor codificar no estilo da equipe, para que o código permaneça consistente em todos os lugares. Em vez de ter seu código diferente de todos os outros.

http://thecodelesscode.com/case/94

Schleis
fonte
3
Eu gostaria que a maioria dos programadores fosse como você. Muitos são questionadamente apaixonados e / ou dogmáticos por seguir o padrão de invólucro que mencionei.
precisa
1
@ Schieé importa se você é o próximo programador a trabalhar no projeto.
N4TKD
3
@oscilatingcretin Você pode acabar sendo tão apaixonado e / ou dogmático depois de trabalhar em um código cheio var m_someVariableID = GetVariableValueId(). Especialmente se você precisar fazer isso sem o suporte ao preenchimento automático.
Tacroy
7
Se você faz parte de uma equipe, é importante seguir o padrão da equipe. Observe, no entanto, que muitas linguagens de programação têm padrões de fato que você deve tentar seguir ao criar um novo projeto em que a equipe não possui padrões (ou onde a equipe se atrasou para defini-los). Se você não tiver certeza de qual convenção de codificação usar, é preferível seguir a convenção usada pelo fornecedor do idioma principal ou pela estrutura incluída, a não ser que você possa justificá-lo.
19713 Brian
2
@ Schleis é uma boa atualização, não concordo que seja apenas uma questão de estilo, mas convenção e convenção se tornam convenções por boas razões e devem ser seguidas. Não é uma religião e, em algum momento, você deve muito da convenção, mas deve ter um bom motivo.
N4TKD
25

1. Por que o padrão existe?

Afinal, não seria melhor deixar todo mundo escrever o código de acordo com a preferência pessoal e parar de falar sobre qual padrão é melhor?

O fato é que, quando você está habituado a um estilo, é mais difícil ler código que usa um estilo diferente. Seu cérebro passa mais tempo tentando entender a convenção (se houver), em vez de entender o que o código faz.

O que é mais legível entre esses dois pedaços de código?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

ou:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Ambos os trechos de código são executados de maneira semelhante. A única diferença é que, no primeiro caso, cada desenvolvedor que trabalhou no projeto usou seu próprio estilo. Isso tornou o código inconsistente, ilegível e perigoso. O fato de os membros da equipe não terem concordado com o tamanho do recuo, juntamente com o fato de que um deles estava se recusando a usar chaves depois que cada um iftornava o código extremamente propenso a erros: olhando para ele, podemos acreditar que o segundo ifé executado somente quando o primeiro iffor verdadeiro, o que não é o caso.

No segundo caso, todos os desenvolvedores seguiram o mesmo padrão. Alguns deles talvez fossem infelizes, porque preferiam recuar dois espaços ou porque estavam acostumados a métodos que começam com uma letra minúscula. O fato é que o código ainda é muito mais legível dessa maneira, e ainda seria se eles estivessem usando algum padrão diferente.

Por ter um padrão rigoroso e uniforme, facilita a leitura do código.

2. Por que o padrão deles é melhor do que o que eu inventei agora?

Se um padrão é usado por centenas de milhares de desenvolvedores em todo o mundo, fique com ele. Não invente você mesmo: mesmo que seja melhor, é mais fácil migrar para o padrão global do que para aquelas centenas de milhares de desenvolvedores para começar a usar o seu.

Exemplo: na minha própria empresa, tenho uma convenção específica para nomear chaves e índices primários e estrangeiros no banco de dados. Esses nomes se parecem com:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] ou
  • [PK for RoleOfPassword: RoleId, PasswordId].

Pessoalmente, acho esta convenção excelente e extremamente clara. Para mim. Mas é totalmente péssimo. É péssimo, porque é meu e porque nenhum dos milhares de administradores de banco de dados nunca o usou. Isso significa que:

  • Quando vou contratar um DBA, ele será forçado a aprender a nova convenção, em vez de começar seu trabalho agora,

  • Não posso compartilhar trechos de código na internet como estão: esses nomes com aparência estranha perturbarão as pessoas que lerão meu código,

  • Se eu pegar o código de fora para usá-lo sozinho, seria obrigado a modificar os nomes para torná-lo uniforme,

  • Se um dia eu decidir usar algum padrão conhecido, serei forçado a modificar todas as centenas de nomes.

3. Então, e a capitalização?

As propriedades têm um escopo ou visibilidade maior que os campos ou variáveis ​​locais. Fazer as propriedades começarem com uma letra maiúscula, e campos e variáveis ​​- com uma pequena vai nessa direção.

Se você considera C #, essa lógica é consistente o suficiente.

Se você considerar Java, os métodos começam com letras minúsculas, o que não segue a lógica.

Portanto, não, não há prova definitiva de que esta convenção seja melhor que a sua. É que esse é usado globalmente e o seu não. Nada é melhor .

Em JavaScript, as funções começam com uma letra minúscula, a menos que exijam um newantes delas. Não seria melhor o contrário? Talvez. O fato é que, durante anos, os desenvolvedores de JavaScript usaram esse padrão, e não o contrário. Reescrever todos os livros e forçar todos os desenvolvedores a mudarem de estilo agora seria um pouco complicado.

Arseni Mourzenko
fonte
1
Quanto à parte sobre o código ser menos legível porque segue um padrão um pouco diferente, nunca tive esse problema. A menos que as variáveis ​​de alguém sejam nomeadas como hookyDookyDoo, nenhuma convenção de nomenclatura ou caso prejudica a legibilidade. Além disso, lembre-se de que não estou dizendo que minha convenção é "melhor", pois não traz realmente nada de especial à tabela de desenvolvimento. Por fim, não entendo seu ponto de vista [Propriedades têm um escopo maior ... segue nessa direção] . O que o escopo tem a ver com a convenção de embalagem? Ir em que direção?
precisa
23
@oscilatingcretin, a questão não é se você já teve esse problema, é se seus colegas têm. Obviamente eles têm, ou eles não estariam reclamando.
Karl Bielefeldt
1
Re: your edit: Seu primeiro exemplo de código demonstra um código simplesmente mal construído e propenso a desastres. Meu OP não é sobre código mal construído e propenso a desastres. É exatamente o mesmo código que o seu segundo exemplo, mas convenção de caixa diferente. Editei seu segundo exemplo de código e o publiquei no meu OP com minha convenção de casos. Substitua isso pelo seu primeiro exemplo de código, por favor.
precisa
5
@oscilatingcretin: O primeiro exemplo de código demonstra não um código mal construído, mas um código escrito por uma equipe em que todos os desenvolvedores seguem seu próprio estilo. Isso acontece com muitas bases de código, com tempo suficiente (por exemplo, cinco anos). Nota: você perdeu o: "O fato é que o código ainda é muito mais legível dessa maneira, e ainda seria se eles estivessem usando algum padrão diferente". ?
Arseni Mourzenko
6
@oscilatingcretin Muitas pesquisas mostram que a consistência diminui significativamente o esforço cognitivo necessário para entender algo que você está lendo. Para prosa regular, ortografia ruim, pontuação ruim e gramática ruim, tudo dificulta a leitura de alguém - independentemente de perceberem isso conscientemente ou não. O código é difícil de ler, sem dificultar - a adesão ao "padrão comum" (para sua pilha de tecnologia de escolha) aumenta a consistência geral e libera neurônios para se concentrar nos negócios importantes do que o código faz, em vez de como está escrito.
Bevan
10

Tecnicamente, isso não importa (ou pelo menos, na maioria dos idiomas, não).

No entanto, a maioria das comunidades de programação (sejam comunidades mundiais que se formaram em torno de um idioma específico, subgrupos dessas comunidades, grupos que se formaram em torno de alguma biblioteca ou kit de ferramentas popular ou apenas equipes individuais) desenvolveram padrões de codificação estabelecidos. Os detalhes exatos são relativamente sem importância (embora em muitos casos, um bom argumento pode ser feito para eles), o que é importante é que você cumpri-los.

Não porque são os melhores, mas porque são o que todo mundo usa; se você seguir o padrão, seu código será consistente com a maioria dos outros códigos que você acabará usando - bibliotecas, código dos colegas de equipe, idiomas incorporados. A nomeação consistente é uma poderosa arma de produtividade, porque significa que quando você adivinha o nome de algo, normalmente adivinhará. É file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? A convenção de nomenclatura lhe dirá.

Carregar suas preferências pessoais em todos os idiomas que encontrar é particularmente perigoso, porque, antes de tudo, todo idioma tem sua própria cultura e as convenções de nomenclatura geralmente são incompatíveis; e segundo, existem muitas diferenças sutis entre os idiomas no que diz respeito à nomeação.

Apenas um exemplo: em C #, tipos e variáveis ​​vivem em espaços para nome separados; o compilador é inteligente o suficiente para saber a diferença. Em C, no entanto, os dois tipos de nomes compartilham um espaço para nome; portanto, você não pode ter um tipo e uma variável com o mesmo nome no mesmo escopo. Por esse motivo, o C precisa de uma convenção de nomenclatura que distinga os tipos das variáveis, enquanto o C # não.

tdammers
fonte
Portanto, parece realmente que alguns idiomas mais antigos abriram caminho para padrões de codificação de idiomas futuros (como o seu exemplo de C / C #). Isso é muito lamentável, porque ter que acompanhar como processar variáveis ​​e membros do objeto apenas adiciona um nível desnecessário de complexidade que pode ser feito sem.
oscilatingcretin
4
@oscilatingcretin Quando todos usam a mesma convenção, ela não adiciona complexidade contínua, a convenção se torna parte do seu modelo mental para o idioma em questão E facilita o uso desse idioma. Isso é demonstrável e mensurável.
Mr.Mindor
Eu ia votar em você, mas você primeiro disse que não importa, depois escreveu vários parágrafos explicando por que isso importa. Se você excluir o "não importa" no início, votarei em você.
Tulains Córdova
10

Estou surpreso que ninguém mais tenha dito isso, mas acho que a diferença de capitalização é incrivelmente útil por um motivo: é bom e conveniente saber se uma variável é apenas de escopo local ou não. Se a variável for local, não me preocupo tanto com os efeitos colaterais de alterá-la, como refatorar o nome. Então, eu gosto de uma convenção que distingue membros da classe versus variáveis ​​de classe privada versus variáveis ​​locais.

Com o Intellisense moderno, isso importa cada vez menos, mas ainda me fornece alguns pontos de referência à medida que leio o código para saber onde devo procurar para encontrar a definição.

E muito disso pode ser deixado do meu pior estilo anos atrás, quando os métodos não eram tão propensos a se encaixar em uma tela.

Jamie F
fonte
Vários projetos nos quais trabalhei especificam algo assim em seu guia de estilo.
Anaximandro
7

Parece mais uma questão de convenções do que sua convenção específica.

Para todas as convenções que você quebra, você está apenas adicionando mais trabalho para todos os outros. Talvez em um mundo perfeito, a empresa inteira trabalhe em um único produto a vida inteira ... no entanto, na realidade, isso não é verdade. As pessoas saltam entre projetos, às vezes entre empresas ou mesmo por diversão. Quanto mais aleatório o código, mais difícil e mais caro é trabalhar. Como proprietário de uma empresa ou parte interessada, eu não gostaria de contratar desenvolvedores que pensam egoisticamente, e não para o bem do projeto.

Isso se resume ao profissionalismo: às vezes precisamos deixar de lado nossos estilos pessoais e seguir o que é mais eficiente para a adoção em massa. Isso incentiva a colaboração e remove barreiras estranhas que não deveriam estar lá em primeiro lugar.

Quanto à sua convenção real, o CapitalCamelCase geralmente é reservado para nomes de classes (ou em Javascript, construtores). Se eu vir uma variável em maiúscula, um palpite instruído determinará que preciso instanciar para usá-la. Se isso estiver errado, ficarei chateado que o código não esteja seguindo os padrões da comunidade. Mesmo com a maioria dos outros idiomas, todo mundo que olha pela primeira vez é instantaneamente enganado. Eu quero que o código seja óbvio, não enganoso.

Adrian Schneider
fonte
"Se eu vir uma variável em maiúscula, um palpite instruído determinará que eu preciso instanciar para usá-la." Eu não entendo. Como ver uma variável em maiúscula faz você pensar que precisa instanciar antes de usá-la? Porque parece um nome de classe? Então você não sabe a diferença entre MyClass MyClass = nulle class MyClass { }?
oscilatingcretin
3
Sim, vejo a diferença. A convenção existe para evitar ambiguidade. var car = new Car();De acordo com a minha última linha - por que não torná-lo óbvio?
Adrian Schneider
3
@oscilatingcretin Há uma diferença, é claro. Mas o cérebro humano se beneficia de pistas visuais que um analisador de computador não precisa. Parece que você está questionando a necessidade de convenções / padrões ... que é uma pergunta válida, se diferente da que você originalmente fez.
Andres F.
2

"porque o caso completo deve ser reservado para propriedades e métodos nulos. Variáveis ​​locais e métodos que retornam um valor devem ter a primeira palavra em letras minúsculas" e porque é uma convenção padrão.

Outros programadores estão puxando seu código agora e achando que isso é uma propriedade e é realmente uma variável local, dificultando o trabalho deles.

N4TKD
fonte
1
Você leu minha pergunta na íntegra? Dê uma olhada no final, onde eu disse: #NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin
8
Sim e Sim, é importante, o próximo programador nunca deve pensar em NuggetCount; você poderá ver o nome e dizer. Um bom livro para ler é "Código Limpo", você deve poder ler o código como uma história e saber o que está acontecendo.
N4TKD
2
@oscilatingcretin Eu acho que a frustração que você está vendo com as pessoas que respondem a perguntas ligeiramente diferentes das que você está perguntando é evidência da confusão que pode ser gerada quando você quebra as convenções aceitas.
Mr.Mindor
7
Convenções carregam significado. Se, de acordo com a convenção, NuggetCount implica uma propriedade, significa que ela tem escopo além do que uma variável local teria. O que significa que tenho que pesquisar mais para determinar esse escopo. Preciso determinar: existem efeitos colaterais para alterá-lo? Posso confiar que seu valor não seja alterado por outro thread enquanto o estiver usando? nuggetCount implica escopo local e devo assumir que toda a história é local.
Mr.Mindor
5
@oscilatingcretin SIM! Exatamente! Eu confiava que o que eles escreveram seguiram a convenção e levaram tudo o que a acompanha. Confiei que eles estavam trabalhando como parte da equipe e pude colher os benefícios de usar essa convenção (sabendo rapidamente o que nuggetCount). Se não o fizeram, provavelmente faço o que seus colegas de trabalho fizeram: tento educar o responsável , e perco mais tempo na próxima vez que tiver que segui-los, não confiando. Por não seguirem a convenção, eles produziram código menos legível e menos sustentável. Você tem um motivo para querer reverter a convenção?
Mr.Mindor
0

Como outros disseram, não há razão real, exceto para obter uma convenção de nomenclatura. Se você conseguir colocar toda a sua equipe na mesma página, provavelmente poderá economizar algum tempo. Por exemplo, pessoalmente, iniciei uma coisa de padrões de codificação que foi usada nisso e usamos o camelCase para todos os variais particulares, bem como as coisas passadas pelo Val, enquanto usamos o PascalCase para coisas públicas e também passadas pela referência.

As linhas ficam um pouco embaçadas ao lidar com coisas como protegido ou Fora ou algo assim.

John
fonte
-2

A linguagem (com seu aspecto formal e convencional) é importante para organizar seus pensamentos, tem poder sobre seus modos de pensar. Portanto, é apenas um sofrimento transitar de um estilo para outro.

Símbolos em maiúsculas e minúsculas têm grandes diferenças semânticas em Haskell, também diferem levemente em Scala e eu usei os dois. Outras linguagens que uso não fazem diferença entre esses dois tipos de identificadores, mas manter os pensamentos da maneira que Haskell percebe os identificadores é muito mais fácil para mim do que fragmentar minha mente em diferentes idiomas.

ayvango
fonte
-2

Para mim, tudo se resume à expectativa.

Quando leio a maioria dos códigos, espero que qualquer coisa que comece com lowerCasea seja uma variável local ou uma função (em C # que seria apenas uma variável). Se eu ProperCasevir uma variável local , provavelmente tropeçarei e ficarei confuso por um tempo, pensando que seja um nome de classe ou uma propriedade ou outra coisa. Isso me faria reler o código e me incomodaria.

É provável que isso esteja acontecendo no seu caso.

Além disso, é conveniente saber qual é o papel de uma variável apenas observando a primeira letra e evita conflitos entre um nome de instância e um nome de classe.

ikh
fonte
-3

Letras minúsculas devem ser usadas para variáveis ​​locais para facilitar a digitação (velocidade / sem tecla shift). Maiúsculas são usadas para facilitar a legibilidade, separando as palavras em um nome. Código com nomes de variáveis ​​locais de uma palavra (que devem ser comuns) é rápido e fácil de digitar. O uso de maiúsculas para cada nova palavra no nome também é mais rápido (e menos espaço) do que usar sublinhados que adicionam outro caractere - isso também é conhecido como maiúsculas e minúsculas.

phkahler
fonte
Penso que esta é uma resposta muito boa e não compreendo os votos negativos. É uma resposta lógica - com base nos fatos solicitados pelo OP. Se você fizer um voto negativo, por favor, explique-se. A tecla Shift pressionada em todo o lugar é enorme. Pense bem, quase todas as palavras que você digitar no seu código iniciarão o PascalCase e, para cada uma delas, será necessário pressionar outra tecla Shift. Se você quer ser minimalista e eficaz, faz sentido remover os pressionamentos desnecessários das teclas Shift. E logicamente falando, você gostaria de ser mais produtivo, o que, de onde estou, significa pressionar menos teclas. Por que pressionar mais?
Aion
-3

Eu concordo com o OP aqui. O camelCase parece errado. Também concordo com o fato de que esse é o padrão e devemos nos ater ao mesmo padrão ou qual é o objetivo de ter um padrão. Também faz sentido que PascalCaps seja usado para métodos etc e camelCase para suas próprias variáveis ​​etc. como uma maneira de diferenciar quando não estiver usando um IDE que colora métodos para você.

Para contornar isso, sempre prefixo os nomes dos meus objetos com o tipo de objeto que é. Portanto, se for uma variável de string, chamo strMyVariable. Se for algum tipo de objeto, chamo de objMyObject, etc. Dessa forma, começa com letras minúsculas conforme o padrão e parece correto.

Filipe
fonte
3
isso parece não oferecer nada substancial sobre os pontos levantados e explicados nas 11 respostas anteriores #
306