Por que ainda há distinção entre maiúsculas e minúsculas em algumas linguagens de programação?

Enquanto a dobra de maiúsculas e minúsculas é bastante trivial em inglês, é muito menos em outros idiomas. Se um programador alemão usa ß em um nome de variável, o que você vai considerar o equivalente em maiúsculas? Apenas FYI, "ß" é somente sempre usado em letras minúsculas. OTOH, "ss" é equivalente - você consideraria um compilador obrigado a combiná-los? Quando você entra no Unicode, tem problemas ainda mais interessantes, como caracteres com marcas diacríticas pré-compostas versus diacríticos combinados separados. Então você chega a alguns roteiros árabes, com três formas separadas de muitas letras, em vez de apenas duas.

Na idade das trevas, a maioria das linguagens de programação não fazia distinção entre maiúsculas e minúsculas, quase por necessidade. Por exemplo, Pascal começou nos mainframes Control Data, que usavam apenas seis bits por caractere (64 códigos, total). A maioria dessas máquinas usava o conjunto de caracteres "CDC Scientific", que continha apenas caracteres maiúsculos. Você poderia alternar para outros conjuntos de caracteres, mas a maioria tinha maiúsculas ou minúsculas, mas não os dois - mas usava os mesmos códigos para ambos. O mesmo aconteceu com os antigos códigos Baudot e tal padrão considerado nos primeiros dias de COBOL, FORTRAN, BASIC, etc. Na época em que hardware mais capaz estava amplamente disponível, o fato de eles não diferenciarem maiúsculas de minúsculas estava tão arraigado que a mudança era impossível. .

Com o passar do tempo, a verdadeira dificuldade da distinção entre maiúsculas e minúsculas tornou-se mais aparente, e os projetistas de idiomas decidiram principalmente ("realizado" seria provavelmente um termo mais preciso) quando / se as pessoas realmente querem insensibilidade a maiúsculas e minúsculas por ferramentas auxiliares do que na própria linguagem.

Pelo menos IMO, o compilador deve receber a entrada exatamente como apresentado, e não decidir que "você escreveu isso, mas vou assumir que você realmente quis dizer outra coisa". Se você quer que as traduções aconteçam, é melhor fazê-las separadamente, com ferramentas criadas para lidar bem com isso.

Por que alguém desejaria insensibilidade a casos? Em que cenário é útil poder referir-se a uma única variável como VARIABLE em um lugar, Variable em outro e variable em um terceiro? A insensibilidade a maiúsculas e minúsculas é exasperante. Eu preferiria receber um erro de compilador quando acidentalmente digitasse VAriable em vez de Variable em vez de permitir que erros de digitação de caso deslizassem no meu código.

Em conclusão, muitas linguagens de programação têm sensibilidade a maiúsculas não apenas por razões históricas / inerciais, mas porque a insensibilidade a maiúsculas e minúsculas é uma idéia ruim.

No caso de Java, a sensibilidade NÃO é usada para fornecer mais opções no código, mas sim para um significado semântico muito claro e consistente. ClassesLookLikeThis. objectsLookLikeThis. methodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. Ele NÃO oferece maior liberdade: ele permite que você coloque algumas informações de forma concisa no que é uma linguagem excessivamente detalhada.

Eu acho que em linguagens explicitamente estaticamente tipadas com mucho compilador e suporte a IDE, a diferenciação de maiúsculas e minúsculas é uma ótima maneira de comunicar informações (por exemplo, Java). Com linguagens como Ruby, a insensibilidade a maiúsculas e minúsculas provavelmente causaria ainda MAIS resultados inesperados, apesar de eu estar aberto para tentar Ruby sem distinção entre maiúsculas e minúsculas.

Acho que a diferenciação de maiúsculas e minúsculas com um sistema estrito não ofusca o código, mas na verdade o torna mais claro. Considere o possível código Java:

      joe blah = new hUf();

isso é bem claro, mas e:

      hUf.WTF();

No Java como está, você saberia automaticamente o que é isso. Em Java não sensível a maiúsculas e minúsculas, é ambíguo, então você precisaria recorrer a algum outro mecanismo para diferenciar classes de instâncias de pacotes de métodos. E esse mecanismo provavelmente faria você vomitar com o quão feio ele é :)

Eu não acho que foi "implementado" tanto quanto "permitido". A diferenciação entre maiúsculas e minúsculas é o estado padrão das comparações de cadeias de caracteres; é necessário trabalho extra para o engenheiro do compilador tornar um caso de linguagem insensível, já que é necessário incluir um código extra para realizar comparações sem distinção entre maiúsculas e minúsculas e preservar os nomes de token originais para gerar relatórios de erros e avisos corretos.

É quase certamente por isso que acabou em C; eles queriam criar uma linguagem simples que fosse fácil de implementar um compilador, em detrimento da usabilidade. Quanto a por que está em linguagens modernas? Porque é em C, é claro, então deve ser o jeito certo de fazer isso! < / sarcasm mode >

Se nada mais, simplifica a análise e permite mais combinações para nomes de variáveis / classes.

Com a análise sem distinção entre maiúsculas e minúsculas, você ficaria restrito a usar identificadores exclusivos, já que 'myClass' e 'MyClass' seriam a mesma coisa. Alternativamente, você teria que adicionar camadas de complexidade ao seu analisador para se certificar de que poderia determinar qual identificador é usado com base no contexto.

Considere um caso como este:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Suponha que a classe XmlWriter também tenha um método estático chamado "Write". Você está chamando-a na instância ou na aula, se não houver distinção entre maiúsculas e minúsculas aplicada aqui?

Eu gosto de distinção entre maiúsculas e minúsculas se, por nenhuma outra razão, tornar o código mais auto-documentado:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Eu normalmente programo em Python, mas em meus dias de c #, achei muito conveniente nomear as instâncias de classe da mesma forma que a classe, mas um caso mais baixo (ou camelo) (como os outros disseram):

Thing thing = new Thing();

O uso de idiomas que não diferenciam maiúsculas de minúsculas requer alguma outra convenção para isso, ou seja, algum tipo de sigilo como:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

O que é uma "coisa ruim".

Eu também acho conveniente usar grep (case-sensitively) para encontrar referência a uma classe versus usos de uma variável. Com uma linguagem que não diferencia maiúsculas de minúsculas, isso seria menos fácil. O mesmo para pesquisa & substituir.

As pessoas prestam atenção ao formato das palavras antes de realmente lê-las. A distinção entre maiúsculas e minúsculas mantém a forma de um símbolo consistente em todo o código. Eu também concordo com aqueles acima que afirmam que diferentes convenções denotam diferentes tipos de símbolos. A sensibilidade ao caso e a insensibilidade podem ser abusadas. Programadores ruins sempre gerarão códigos ruins ... eles encontrarão um caminho.

Pegue a linguagem como um exemplo. Por que começamos frases e nomeamos coisas com maiúsculas ... É também por causa do unix?

Eu acho que para linguagens estaticamente tipadas como C # e Java, isso não adiciona nenhum valor. Como na maioria dos casos, você tem um IDE que corrige automaticamente as incompatibilidades de maiúsculas e minúsculas para você, então, no final do dia, se eu digitar "VAriable" por acidente, meu IDE corrigirá automaticamente isso para " Variável "para mim. Acrescente a isso as convenções de estilo MyClass myClass; e você pode ver que a distinção entre maiúsculas e minúsculas não é necessariamente uma coisa ruim.

Para linguagens tipificadas dinamicamente, pode haver mais de um argumento, já que é mais difícil para um IDE adivinhar uma autocorreção, mas no caso de linguagens dinamicamente tipadas, você já tem muito mais com o que se preocupar ( em termos de erros de digitação), o fato de usar uma convenção de invólucro consistente não vai acrescentar muito mais carga.

Então, sim, embora não exista uma razão real pela qual as linguagens possam não não diferenciar maiúsculas de minúsculas, também não há motivo real para que elas sejam .

Esse artigo de Scott Hanselman sobre "SignOn" vs "Signon" foi sobre comparações de strings e nada a ver com linguagens de programação. Concordo que as strings que os usuários digitam sempre devem comparar sem distinção entre maiúsculas e minúsculas, mas acho que é um jogo diferente para os identificadores em uma linguagem de programação.

Quando uma linguagem faz distinção entre maiúsculas e minúsculas, aproveito-a para reproduzir o uso convencional de casos em matemática e ciências. Aqui está uma lista (de forma alguma exaustiva) de algumas convenções de casos:

• Na teoria da probabilidade,% min_co% geralmente representa uma função de densidade de probabilidade (pdf), enquanto% de f representa a função de distribuição cumulativa correspondente (cdf).
• Também na teoria da probabilidade, letras maiúsculas denotam variáveis aleatórias F e as letras minúsculas correspondentes denotam suas realizações X , como em $ Pr [X = x] \ leq 0,05 $.
• Na álgebra linear, as letras maiúsculas são geralmente usadas para se referir a matrizes, enquanto letras minúsculas geralmente são usadas para se referir a números, por exemplo, $ A = [a_ {ij}] $.
• Os símbolos das unidades são escritos em letras minúsculas (por exemplo, m para metro), exceto para liter (L) e aquelas derivadas do nome de uma pessoa (W para Watt, Pa para Pascal, N para Newton e assim por diante ).
• Símbolos de prefixos que significam um milhão ou mais são capitalizados (M para mega (milhões)) e aqueles com menos de um milhão são minúsculas (m para milli (milésimos)).

Eu achei que era por causa do Unix e do C - mas esse é um tipo de problema de galinha e ovo que somente os velhotes podem responder adequadamente.

Eu uso o raciocínio que as galinhas em "O coelhinho da Páscoa está chegando à cidade" usado quando perguntado se eles vieram antes de ovos. Porque havia galinhas na Arca de Noé, as galinhas vinham primeiro. Portanto, como o GCC é executado no Unix, o Unix veio primeiro, portanto, porque o Unix se importa tanto com o caso, C e todas as suas variantes e descendentes, sim qualquer coisa que imponha chaves, cuida do caso.

Há provavelmente um link entre chaves e diferenciação de maiúsculas e minúsculas.

Além das excelentes respostas dadas até agora, gostaria de salientar que a distinção entre maiúsculas e minúsculas também oferece "namespaces" adicionais. Por exemplo, o Perl tem alguns blocos especiais como BEGIN e END que são executados em horários diferentes do código normal (BEGIN em tempo de compilação, END após o término normal do programa), e com aqueles em maiúsculas os fazem sobressair, e significa que as variantes de letras minúsculas não são palavras reservadas.

Pode-se ir ainda mais longe e reservar nomes com todas as letras maiúsculas para uso futuro pelo idioma, e não cause nenhum dano aos programadores normais, que normalmente NÃO QUEREM EM SEU CÓDIGO.

"Com distinção entre maiúsculas e minúsculas" é sempre melhor para as pessoas técnicas reduzirem a ambigüidade. Tome o nome do arquivo como um exemplo. Lidar com o nome do arquivo do Windows é mais problemático do que o nome do arquivo Unix porque o nome do arquivo no Windows não faz distinção entre maiúsculas e minúsculas, enquanto o nome do arquivo no Unix faz distinção entre maiúsculas e minúsculas.

Voltar para a programação. Para o nome da classe, nome do método, nome da variável, a maioria dos idiomas não impõe a regra de estilo de nomenclatura. Às vezes, para simplificar a "reflexão", podemos simplesmente usar o nome "Case sensitive" para vincular a outra fonte de dados sem conversão, ou lidar com o problema do mesmo nome, mas em casos diferentes.

Estou surpreso com esse discurso. Agora que ninguém quer que você use um sublinhado ou um m_ em um nome de campo em C #, acabei de usar o camel case, e se o nome do campo é o mesmo que um nome de propriedade pública, apenas o nome da propriedade pública é o caso Pascal e o campo de apoio é o caso do camelo, eu acho, "assim seja" - é o que a comunidade de programação em geral parece querer. Não causou nenhum problema até agora.

Especialmente algum programador vem dos primórdios do BASIC, onde um nome de variável pode ter apenas 2 caracteres.

E assim, quando pode ser qualquer número de personagens, eles ficam muito felizes. E junto com a diferenciação de maiúsculas e minúsculas - porque eles não querem também se preocupar com SomeName sendo acidentalmente igual a SOMENAME e causar um bug devido a coisas como esta.