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

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);
    }
}

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.

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

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.

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.

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.

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.

"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.

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.

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.

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.

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.

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.