Não vejo utilidade para a distinção entre maiúsculas e minúsculas em uma linguagem de programação, além do código ofuscante.
Por que implementar isso em uma linguagem de programação?
Atualizar:
Parece que alguém que você conhece fez uma declaração sobre isso .
programming-languages
syntax
DavRob60
fonte
fonte
Person person = new Person()
na linguagem OO, onde o símbolo 'pessoa' é um objeto temporário e 'Pessoa' é um tipo de classe.Respostas:
Embora a dobra de casos seja bastante trivial em inglês, é muito menos em alguns outros idiomas. Se um programador alemão usa
ß
um nome de variável, o que você considera o equivalente em maiúsculas? Apenas para sua informação, "ß" é usado apenas em letras minúsculas. OTOH, "ss" é equivalente - você consideraria um compilador obrigado a combiná-los? Quando você entra no Unicode, obtém problemas ainda mais interessantes, como caracteres com marcas diacríticas pré-compostas e diacríticos combinados separados. Então você começa alguns scripts em árabe, com três formas separadas de muitas letras, em vez de apenas duas.Na idade das trevas, a maioria das linguagens de programação diferenciava maiúsculas de minúsculas quase por necessidade. Por exemplo, Pascal começou nos mainframes dos Dados de Controle, 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 mudar para outros conjuntos de caracteres, mas a maioria tinha letras maiúsculas ou minúsculas, mas não as duas - mas usava os mesmos códigos para ambas. O mesmo aconteceu com os códigos Baudot antigos e considerados padrão nos primeiros dias de COBOL, FORTRAN, BASIC, etc. Quando o hardware mais capaz estava amplamente disponível, a distinção entre maiúsculas e minúsculas era tão arraigada que a alteração era impossível. .
Com o tempo, a real dificuldade de diferenciar maiúsculas de minúsculas tornou-se mais aparente, e os designers de linguagem decidiram ("percebido" provavelmente seria um termo mais preciso) que quando / se as pessoas realmente querem insensibilidade a maiúsculas e minúsculas, é melhor manipulado por ferramentas auxiliares do que na própria linguagem.
Pelo menos na 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ê deseja que as traduções ocorram, é melhor fazê-las separadamente, com ferramentas criadas para lidar bem com isso.
fonte
Por que alguém iria querer insensibilidade ao caso? Em que cenário é útil poder se referir a uma única variável como
VARIABLE
em um lugar,Variable
em outro evariable
em um terceiro? Insensibilidade ao caso é exasperante. Prefiro obter um erro de compilador quando digito acidentalmente,VAriable
emVariable
vez de deixar erros de digitação como esse entrarem no meu código.Em conclusão, muitas linguagens de programação têm distinção entre maiúsculas e minúsculas, não apenas por razões históricas / inerciais, mas porque a insensibilidade a maiúsculas e minúsculas é uma má idéia.
fonte
No caso Java, a sensibilidade NÃO é usada para fornecer mais opções no código, mas para um significado semântico muito claro e consistente. ClassesLookLikeThis. objectsLookLikeThis. methodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NÃO oferece maior liberdade: permite que você coloque algumas informações de forma concisa no que é uma linguagem excessivamente detalhada.
Eu acho que em linguagens explicitamente tipadas estaticamente com compilador mucho e suporte a IDE, a distinção entre maiúsculas e minúsculas é uma ótima maneira de comunicar informações (por exemplo, Java). Em idiomas como Ruby, a distinção entre maiúsculas e minúsculas provavelmente causaria ainda mais resultados inesperados, embora eu estivesse aberto a tentar Ruby sem distinção entre maiúsculas e minúsculas.
Penso que a distinção entre maiúsculas e minúsculas com um sistema rigoroso não ofusca o código, mas na verdade o torna mais claro. Considere o possível código Java:
isso é bem claro, mas e quanto a:
No Java como está, você saberia automaticamente o que é isso. No Java que não diferencia maiúsculas de minúsculas, é ambíguo; portanto, você precisa recorrer a 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 é :)
fonte
Eu não acho que foi "implementado" tanto quanto "permitido". A distinção entre maiúsculas e minúsculas é o estado padrão das comparações de strings; é necessário um trabalho extra para o engenheiro do compilador tornar um idioma sem distinção entre maiúsculas e minúsculas, pois é necessário adicionar código extra para realizar comparações sem distinção entre maiúsculas e minúsculas e preservar os nomes de tokens originais para corrigir erros e relatórios de aviso.
É quase certamente por isso que acabou em C; eles queriam criar uma linguagem simples e fácil de implementar um compilador, às custas da usabilidade. Quanto ao motivo pelo qual está nos idiomas modernos? Porque está em C, é claro, então deve ser o caminho certo para fazê-lo! </ modo sarcasmo>
fonte
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ê estaria restrito a usar identificadores exclusivos, pois 'myClass' e 'MyClass' seriam a mesma coisa. Como alternativa, você teria que adicionar camadas de complexidade ao seu analisador para garantir que você pudesse determinar qual identificador é usado com base no contexto.
Considere um caso como este:
Suponha que a classe XmlWriter também tenha um método estático chamado "Write". Você está chamando na instância ou na classe, se não houver distinção entre maiúsculas e minúsculas aplicada aqui?
fonte
write
eWrite
fosse dois métodos completamente diferentes.Gosto da distinção entre maiúsculas e minúsculas se, por outro motivo, não tornar o código mais auto-documentável:
Normalmente programa em Python, mas nos meus dias de C #, achei muito conveniente nomear instâncias de classe da mesma forma que a classe, mas com letras minúsculas (ou camelos) (como outros já disseram):
O uso de linguagens que não diferenciam maiúsculas de minúsculas requer alguma outra convenção para isso, ou seja, algum tipo de sigilo como:
O que é uma "coisa ruim".
Também acho conveniente grep (com distinção entre maiúsculas e minúsculas) para encontrar referência a uma classe vs. 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 e substituição.
Por fim, como programador, quando vejo palavras com casos diferentes, percebe-se que são coisas diferentes ... Eu raramente tenho bugs em que casos variáveis estavam errados, mesmo em linguagens dinâmicas e com scripts em que um compilador teria ajudado.
fonte
As pessoas prestam atenção ao formato das palavras antes de 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. Também concordo com aqueles acima que afirmam que diferentes convenções denotam diferentes tipos de símbolos. A sensibilidade e insensibilidade ao caso podem ser abusadas. Os programadores ruins sempre geram códigos ruins ... eles encontrarão uma maneira.
Tome a linguagem como exemplo. Por que começamos frases e nomeamos coisas com maiúsculas ... É também por causa do unix?
fonte
Eu acho que para linguagens de digitação estática, como C # e Java, ele realmente não agrega nenhum valor. Como na maioria dos casos, você tem um IDE que corrige automaticamente as diferenças de maiúsculas e minúsculas para você, portanto, no final do dia, se eu digitar "VAriable" por acidente, meu IDE corrigirá isso automaticamente para " Variável "para mim. Acrescente a isso as
MyClass myClass;
convenções de estilo e você pode ver que a distinção entre maiúsculas e minúsculas não é necessariamente uma coisa ruim.Para linguagens de tipo dinâmico, pode haver mais argumento, já que é mais difícil para um IDE adivinhar uma autocorreção, mas no caso de linguagens de tipo dinâmico, você já tem muito mais com o que se preocupar (em termos de erros de digitação) de que o uso de uma convenção de caixa consistente não trará muito mais carga.
Portanto, sim, embora não haja uma razão real para que as línguas não possam fazer distinção entre maiúsculas e minúsculas, também não há uma razão real para que elas também sejam.
Esse artigo de Scott Hanselman sobre "SignOn" vs "Signon" era sobre comparações de strings e nada a ver com linguagens de programação. Concordo que as strings que os usuários digitam devem sempre ser comparadas sem distinção entre maiúsculas e minúsculas, mas acho que esse é um jogo diferente dos identificadores em uma linguagem de programação.
fonte
Quando uma linguagem diferencia maiúsculas de minúsculas, aproveito-a para reproduzir o uso convencional de casos em matemática e ciências. Aqui está uma lista (de maneira alguma exaustiva) de algumas convenções de casos:
f
geralmente representam uma função de densidade de probabilidade (pdf), enquanto letras maiúsculasF
representam a função de distribuição cumulativa correspondente (cdf).X
e as letras minúsculas correspondentes indicam suas realizaçõesx
, como em $ Pr [X = x] \ leq 0,05 $.fonte
Eu apenas imaginei que era por causa do Unix e C - mas isso é uma espécie de problema de galinha e ovo, que apenas os velhotes podem responder adequadamente.
Eu uso o raciocínio que as Galinhas em "O Coelhinho da Páscoa estão chegando à cidade" usaram quando perguntadas se elas vieram antes de Eggs. Porque havia galinhas na Arca de Noé, as galinhas vieram primeiro. Portanto, como o GCC roda no Unix, o Unix ficou em primeiro lugar; portanto, porque o Unix se importa tanto com maiúsculas e minúsculas, C e todas as suas variantes e descendentes, sim, qualquer coisa que imponha chaves, se importa com maiúsculas e minúsculas.
Provavelmente também existe um vínculo entre chaves e distinção entre maiúsculas e minúsculas.
fonte
Além das excelentes respostas dadas até agora, gostaria de salientar que a distinção entre maiúsculas e minúsculas fornece também "namespaces" adicionais. Por exemplo, o Perl possui alguns blocos especiais como
BEGIN
eEND
que são executados em momentos diferentes do código normal (BEGIN em tempo de compilação, END após o término do programa normal), e ter aqueles como maiúsculas os faz sobressair e significa que as letras minúsculas variantes não são palavras reservadas.Pode-se ir ainda mais longe e reservar nomes com letras maiúsculas para uso futuro pela linguagem, e não prejudicar os programadores normais, que geralmente NÃO ATUAM EM SEU CÓDIGO.
fonte
"Diferenciar maiúsculas de minúsculas" é sempre melhor para as pessoas técnicas reduzirem a ambiguidade. Tome o nome do arquivo como exemplo. Lidar com o nome do arquivo do Windows é mais problemático que o nome do arquivo do Unix, porque o nome do arquivo no Windows não diferencia maiúsculas de minúsculas, enquanto o nome do arquivo no Unix diferencia maiúsculas de minúsculas.
Voltar à programação. Para o nome da classe, o nome do método, o nome da variável, a maioria dos idiomas não aplica a regra do estilo de nomeação. Às vezes, para simplificar a "reflexão", podemos simplesmente usar o nome "Case sensitive" para ligar a outra fonte de dados sem conversão, ou lidar com o problema do mesmo nome, mas em casos diferentes.
fonte
Estou surpreso com este discurso retórico. Agora que ninguém deseja que você use um sublinhado ou um
m_
nome de campo em C #, acabei de usar camel case e, se o nome do campo for igual ao nome de uma propriedade pública, apenas o nome da propriedade pública será Pascal case e o campo de apoio é o caso dos camelos, imagino, "assim seja" - é o que a comunidade de programação em geral parece querer. Não causou nenhum problema até agora.fonte
Especialmente, alguns programadores vêm dos primeiros dias do BASIC, onde um nome de variável pode ter apenas 2 caracteres.
E assim, quando pode haver qualquer número de caracteres, eles ficam muito felizes. E junto com a distinção entre maiúsculas e minúsculas - porque eles também não querem se preocupar em
SomeName
ser acidentalmente iguaisSOMENAME
e causar um bug devido a coisas como essa.fonte