Palavras-chave que não diferenciam maiúsculas de minúsculas em um idioma [fechado]


31

Estamos tentando escrever uma linguagem de script personalizada. Houve uma sugestão para tornar o idioma perdoador, fornecendo palavras-chave que não diferenciam maiúsculas de minúsculas .

Pessoalmente, não gosto da ideia, mas há poucas pessoas na minha equipe que se inclinam para ela, dizendo que isso fará o usuário final feliz! Exemplos de linguagens como FORTRAN, BASIC, SQL são fornecidos dizendo que não diferenciam maiúsculas de minúsculas.

isso é uma boa ideia?


4
Bem, o Visual Basic geralmente não diferencia maiúsculas de minúsculas, isso responde à sua pergunta? ; P
yannis


3
Observe que é muito difícil tornar os identificadores sem distinção entre maiúsculas e minúsculas, a menos que você limite os usuários ao conjunto de caracteres ASCII.
Simon Richter

2
@ MainMa: C ++ pelo menos não diretamente. Ele permite caracteres definidos pelo implementação do identificador, mas o que é garantido apenas a-zA-Z, 0-9(exceto no início) e _.
Xeo 24/09/12

2
O VB6 realmente usa um tipo de abordagem híbrida: você pode escrever palavras-chave e identificadores da maneira que desejar e o IDE os converte imediatamente na maneira armazenada. (Você pode até escrever "endif" e será convertido em "End If".)
Felix Dombek

Respostas:


42

Pergunte a si mesmo quem é o usuário final. Se ele deve ser escrito por alguém com experiência em programação em C ou Javscript, ou experiência em TI no Unix, a distinção entre maiúsculas e minúsculas é provavelmente a coisa certa a se fazer, porque é isso que o usuário espera. Mas para a maioria dos usuários finais, mesmo os usuários avançados, isso será confuso.

VB / VBA / VBScript não diferenciam maiúsculas de minúsculas, e essa foi uma decisão tomada para permitir que não-programadores entendessem facilmente a linguagem. As fórmulas do Excel, não exatamente os scripts, mas o número de usuários mais próximo, não diferenciam maiúsculas de minúsculas. Na maioria dos escritos, a escolha de maiúsculas e minúsculas pode fazer com que o texto pareça mais ou menos profissional e polido, mas caso ele não mude o significado semântico das palavras. É por isso que acredito que os não desenvolvedores ficarão confusos com uma linguagem de script que diferencia maiúsculas de minúsculas.

Novamente, essa não é uma escolha técnica. É uma escolha de gerenciamento de produtos que deve ser feita pelas pessoas que conhecem bem o público-alvo.


Pense em quais sistemas de arquivos diferenciam maiúsculas de minúsculas antes de examinar as linguagens de programação. FAT / NTFS para Windows e HFS + para MacOS X não fazem distinção entre maiúsculas e minúsculas, enquanto UFS / NFS para Unix diferenciam maiúsculas de minúsculas. Usuários avançados gostam da capacidade de distinguir arquivos / variáveis ​​por pequenas diferenças, enquanto a maioria dos usuários prefere manter as coisas mais intuitivas. Como diz Avner, a diferença é uma escolha de gerenciamento de produtos.
Michael Shopsin

4
Como é uma linguagem de script, é fácil de entender - a insensibilidade ao caso é o caminho a seguir. Por que diferencia maiúsculas de minúsculas? Se a resposta é "ser como C e Java", essa é realmente uma boa razão?
Ben

15
@Ben Python, Ruby, bash, Lua e Perl são exemplos de linguagens de script muito populares que diferenciam maiúsculas de minúsculas. Linguagens que não diferenciam maiúsculas de minúsculas incluem linguagens corporativas como Delphi e SQL (e COBOL IIRC, se você contar isso). Por que é um acéfalo para as linguagens de script e por que os designers das maiores linguagens de script do mundo discordam?

2
Não pode ser um acéfalo por ser uma linguagem de script - a questão relevante é: quem está fazendo o script e qual é a melhor opção para eles? (I também dizer que você provavelmente deve ser consistente: se as palavras-chave são insensíveis ao caso, por favor, não faça os identificadores maiúsculas de minúsculas ...)
comingstorm

@ delnan Eu acho que é uma escolha lógica que a linguagem de script direcionada ao sistema operacional em que a diferenciação entre maiúsculas e minúsculas esteja integrada também deva diferenciar maiúsculas de minúsculas.
Artemix

16

Você deve decidir com base na experiência do usuário que deseja apresentar, e não no quão fácil ou difícil é implementar.

Se isso facilitará a insensibilidade de maiúsculas e minúsculas aos usuários, é isso que você deve implementar.

Como exemplo, o SQL não faz distinção entre maiúsculas e minúsculas. Isso facilita muito o uso em um ambiente interativo.

Outra maneira de analisar isso é que haverá alguma diferença entre keyworde Keywordno seu idioma, e será essa diferença significativa para o usuário? Para uma linguagem de script, eu diria que a resposta é "não".


3
+1 em "essa diferença será significativa para o usuário". O usuário é o mais importante.
Ben

Por que o SQL é mais fácil de usar em uma configuração interativa devido à distinção entre maiúsculas e minúsculas? É porque você pode ativar acidentalmente o Caps Lock e não perceber?
Kaz

@Kaz - Praticamente.
ChrisF

11

As linguagens de programação devem diferenciar maiúsculas de minúsculas. As pessoas podem se ajustar a isso com muita facilidade: elas simplesmente precisam se lembrar de trabalhar principalmente em letras minúsculas e observar os identificadores de maiúsculas ou minúsculas nas APIs existentes.

Parecia óbvio tornar as línguas sem distinção entre maiúsculas e minúsculas. Isso ocorre porque as letras minúsculas não estavam disponíveis em todos os sistemas de computação e seus dispositivos de E / S (teclados, impressoras e dispositivos de exibição). As implementações da linguagem de programação precisavam aceitar programas escritos em maiúsculas, pois somente isso poderia ser exibido ou impresso. E para isso eles tinham que ser insensíveis a maiúsculas, porque aceitar maiúsculas e diferencia maiúsculas de minúsculas significa rejeitar letras minúsculas. Minúsculas era algo que os programadores queriam, mas nem sempre podiam ter. Ninguém realmente queria trabalhar com programas que gritavam em maiúsculas; era apenas uma limitação de hardware.

Por um tempo, era comum até dobrar caixas em terminais. Se um terminal pudesse exibir apenas maiúsculas, mas você tivesse que fazer login em um sistema de computação que suporta maiúsculas e minúsculas, o terminal dobraria a minúscula para maiúscula. Acha que isso foi há tanto tempo atrás? "Como o Apple II, o Apple II Plus não tinha funcionalidade em minúsculas." (http://en.wikipedia.org/wiki/Apple_II_Plus) Quando os usuários dos primeiros computadores da Apple discavam em um BBS com conteúdo em maiúsculas e minúsculas, o emulador de terminal (ou host) precisava dobrá-lo para maiúsculas. Mensagens escritas em maiúsculas eram comuns em quadros de avisos naqueles dias. Essa funcionalidade ainda é encontrada em sistemas operacionais semelhantes ao Unix, como o kernel do Linux. Por exemplo, digite o stty olcucprompt no seu shell.A disciplina de linha tty do Unix pode mapear letras minúsculas para maiúsculas na saída e pode mapear maiúsculas para minúsculas na entrada. Isso permite que você trabalhe em uma linguagem de programação em letras minúsculas, em um terminal que não possui letras minúsculas.

Insensibilidade a maiúsculas e minúsculas é um conceito desatualizado de uma era passada de computadores que não funciona muito bem no mundo moderno da computação internacionalizada. Você estende isso para outros idiomas? Que tal francês: você considera È e è equivalente? Ou japonês? Você considera hiragana e katakana apenas casos, para que フ ァ イ ル e ふ ぁ い る sejam o mesmo identificador? O suporte a essa loucura complicará bastante o seu analisador lexical, que precisará ter mapas de equivalência de casos para todo o espaço Unicode.

Observe que a matemática diferencia maiúsculas de minúsculas. Por exemplo, o sigma maiúsculo pode denotar soma, enquanto o sigma minúsculo denota outra coisa, como desvio padrão. Isso pode ocorrer na mesma fórmula sem criar dificuldades. (A linguagem de programação tornará Σ e σ equivalente?)

A ortografia em inglês é sensível. Por exemplo, muitos substantivos próprios correspondem a substantivos comuns ou mesmo a outras partes do discurso. "may" é um verbo, mas "may" é um mês ou o nome de uma mulher. Além disso, se um acrônimo ou abreviação for escrito em letras minúsculas, poderá ser confuso. SAT significa teste de aptidão escolar, enquanto "sat" é o particípio passado de "sit". Pessoas inteligentes prestam atenção aos detalhes e capitalizam adequadamente.

Basicamente, qualquer nova linguagem de programação criada desde 1985, que não diferencia maiúsculas de minúsculas, é PARA AQUELES QUE AINDA CHAMAM EM E-MAILS E POSTAGENS SEM SEGUNDO PENSAMENTO.

E se o seu idioma for usado como destino de geração de código para traduzir código em outro idioma e esse outro idioma for sensível a maiúsculas e minúsculas? Você terá que, de alguma forma, transformar todos os nomes para capturar a distinção. (Portanto, afirmar que esta não é uma decisão técnica, e apenas questão das preferências emocionais do público-alvo, é ridículo.)

Observe os problemas irritantes causados ​​pelo tratamento de casos no Windows, quando os arquivos são importados de outro sistema operacional. Essa é uma questão técnica. Os sistemas de arquivos com distinção entre maiúsculas e minúsculas têm um problema com dados externos que não diferenciam maiúsculas de minúsculas.

O Lisp comum atingiu a abordagem ideal: os nomes dos símbolos diferenciam maiúsculas de minúsculas, mas quando os tokens são lidos, eles são dobrados para maiúsculas. Isto significa que os tokens foo, fOO, FOOe Foodenotam o mesmo símbolo: o símbolo cujo nome é armazenado como a cadeia de caracteres "FOO". Além disso, esse comportamento é apenas a configuração da tabela de leitura padrão. O leitor pode dobrar as letras para maiúsculas, minúsculas, inverter a caixa ou preservá-la. As duas últimas opções dão origem a um dialeto que diferencia maiúsculas de minúsculas. Dessa forma, os usuários têm a máxima flexibilidade.


1
"E o francês: você considera È e é equivalente? Ou japonês? Você considera hiragana e katakana apenas casos, para que フ ァ イ ル e ふ ぁ い る sejam o mesmo identificador?" A resposta é "sim", e só é tolice se você pensa que a cultura de outras pessoas é tola.
Ben

Bem, prepare-se para a sua cabecinha explodir, porque eu não acho que as culturas de outras pessoas sejam tolas (com certas exceções, em relação aos eventos atuais do mundo), mas ao mesmo tempo eu acho que é completamente idiota tratar treat ァ イ eる ぁ い る como o mesmo identificador em uma linguagem de programação.
Kaz

@Ben você conhece as culturas mencionadas? Se você soubesse do que Kaz estava falando, não o chamaria de tolo.
22412 David Cowden

1
@ DavidCowden, em nenhum momento chamei Kaz de tolo. Concordo que sempre se deve usar o mesmo caso sempre que se usa um identificador. A diferença de kana é mais significativa do que a diferença de maiúsculas e minúsculas, assim como a diferença de sotaque é mais significativa que a diferença de maiúsculas e minúsculas. No entanto, assim como é tolo ter dois identificadores que diferem apenas por caso, também é tolo ter dois identificadores que diferem apenas por kana ou sotaque. Faz mais sentido proibir identificadores que diferem apenas por kana ou sotaque do que tratá-los da mesma forma, mas faz muito pouco sentido tratá-los como diferentes.
Ben

Se você proíbe identificadores que diferem apenas em maiúsculas e minúsculas, sotaque ou kana ou qualquer outra coisa, então você está admitindo tacitamente que eles são os mesmos (mas apenas insistindo na consistência). É melhor não banir essas coisas e deixá-las para os usuários como uma questão de convenção de codificação. Uma idéia melhor seria ter um sistema declarativo pelo qual o programa possa afirmar isso fooe Foodeve ser tratado como sinônimo ou distinto. Sem essa declaração, é um erro que os dois ocorram. E como a declaração não se estende a FOO, FOOainda é proibida; tem que ser adicionado.
Kaz

6

O verdadeiro fator determinante é a frequência com que você deseja ter várias coisas com o mesmo nome. A distinção entre maiúsculas e minúsculas funciona no SQL, porque muitas vezes você não deseja uma coluna denominada SELECT. Seria irritante em Java porque todas as outras linhas se parecem Object object = new Object(), onde você deseja que o mesmo nome se refira a uma classe, uma instância e um construtor.

Em outras palavras, a distinção entre maiúsculas e minúsculas é útil principalmente para sobrecarregar um nome e a sobrecarga é principalmente útil em projetos grandes e complexos. Para uso pouco frequente, como uma linguagem de script, a distinção entre maiúsculas e minúsculas pode tornar a programação muito mais simples.

Eu criei uma linguagem de regras uma vez em que os identificadores não apenas diferenciavam maiúsculas de minúsculas, mas também em branco. Também permiti a criação de aliases que se referiam ao mesmo identificador. Por exemplo, ProgrammersStackExchange, programadores de troca de pilhas e PSE resolveram exatamente o mesmo símbolo e poderiam ser usados ​​de forma intercambiável.

Para o meu domínio, isso funcionou muito bem, porque o domínio tinha muitas maneiras extremamente conhecidas de se referir à mesma coisa, e os conflitos de nomes eram raros. Ninguém ficaria surpreso digitando uma consulta usando um nome e tendo o resultado usando outro. O suporte ao idioma facilitou muito a tradução entre o domínio e a linguagem de programação. No entanto, também tornou algumas tarefas mais difíceis, como encontrar todas as referências a uma variável. Felizmente, no meu caso, esses tipos de situações raramente surgiam ou eram razoavelmente fáceis de criar suporte de ferramentas para ajudar, mas você precisa levar sua própria situação em consideração.


Não acho que querer reutilizar palavras-chave para nomes seja o problema. SQL, Visual Basic e C # (os dois primeiros não diferenciam maiúsculas de minúsculas e o segundo diferencia maiúsculas de minúsculas) resolvem isso, permitindo uma maneira de citar identificadores: "double quotes"(ou [brackets]no MS SQL) no SQL, [brackets]no VB.net e @atsignno C #.
usar o seguinte comando

"com que frequência você deseja ter várias coisas com o mesmo nome". Insensibilidade a maiúsculas e minúsculas significa que você deve adicionar uma sobrecarga para nomes não ambíguos que seriam tratados por maiúsculas e minúsculas (por exemplo, m como prefixo para 'membro' diferenciar de um nome de propriedade sem prefixo, digamos).
Nwahmaet 24/09/12

Por que você nomearia um objeto? Isso está apenas pedindo problemas.
Ben

@ Ben, suponha que você esteja implementando um objeto contêiner, o que mais você chamará de parâmetro para seu método add?
Winston Ewert

@WinstonEwert, eu diria o. Realmente não importa como você chama, pois é apenas um nome de parâmetro. Contanto que não seja ofensivo ou ilegal, ou possa causar confusão .
Ben

5

Supondo que sua linguagem de script faça distinção entre maiúsculas e minúsculas - você criará um compilador ou verificador de sintaxe que informará o usuário se ele digitar um erro de digitação usando o caso errado em um nome de variável ou palavra-chave? Caso contrário, esse seria um argumento muito forte para tornar a linguagem insensível.


Bom ponto, mas não uma resposta.

@ delnan: talvez não seja uma resposta tão boa quanto a de Avner Shahar-Kashtan (a quem dei +1), mas provavelmente útil para o OP.
Doc Brown

3
Sim, útil como um comentário;)

Portanto, se isso for reformulado para dizer que é apenas uma boa idéia, se você avisar o usuário sobre a distinção entre maiúsculas e minúsculas, seria uma resposta? Para mim, isso foi assumido.
Jeffo

Não, então seria um ponto menor que dificilmente está respondendo à pergunta formulada como resposta. NA MINHA HUMILDE OPINIÃO.

4

Você pode declarar variáveis ​​on-the-fly? Nesse caso, eu argumentaria contra distinção entre maiúsculas e minúsculas, como rastrear um bug causado por

ATypo = 42; 

em oposição a

Atypo = 42; 

é desnecessário pedir tempo de depuração, quando ter as duas instruções equivalentes apenas facilita a vida.


2
IMHO também facilita a leitura. Afinal, quando você inicia uma frase, você coloca a primeira palavra em maiúscula, mas você não muda seu significado. O mesmo deve ser para o código!
NWS

2
@ delnan - você queria legibilidade, ele usa o mesmo alfabeto. Por que mudar o significado quando você muda de caso?
NWS

1
@delnan, de acordo com a Suprema Corte dos Estados Unidos da América, as linguagens de computador são uma linguagem expressiva projetada para ser entendida por computadores e humanos (ao decidir que o código de computador está protegido pela primeira emenda). Eles não são ingleses, mas são um idioma, e dizer "BOB" é diferente de "bob" é diferente de "Bob" é idiota em qualquer idioma destinado a ser usado por seres humanos. Sim, podemos aprender a lidar com isso, mas isso não é desculpa nenhuma.
Ben

2
@ Ben Deixe-me fazer uma analogia. A notação matemática é, diferentemente das linguagens de programação, exclusivamente para humanos. O argumento usual de que a insensibilidade de caso é um artefato histórico de computadores antigos não se aplica aqui. No entanto, duvido que qualquer matemático argumentaria isso ae Adeveria ser intercambiável. Eles são consistentes, sem exceções. Por exemplo, em alguns contextos, as letras maiúsculas são usadas para conjuntos, enquanto as letras minúsculas são membros do conjunto. Outro exemplo ocorre na engenharia elétrica, em minúsculas, dependendo do tempo, e em maiúsculas, independente do tempo ...

2
@ Ben ... nesses e em outros contextos, não vejo a distinção entre maiúsculas e minúsculas como uma restrição. Eu vejo isso liberando símbolos redundantes para serem usados ​​de maneira mais produtiva, por meio de convenções que comunicam significado através de, entre outros meios, capitalização. Como qualquer notação concisa e específica de domínio, isso pode parecer estranho ao leigo, mas permite que os especialistas se comuniquem melhor e mais rapidamente.

2

Exemplos de linguagens como FORTRAN, BASIC, SQL são fornecidos dizendo que não diferenciam maiúsculas de minúsculas.

O motivo pelo qual FORTRAN e SQL (e COBOL) não diferenciam maiúsculas de minúsculas é que eles foram originalmente projetados para uso em máquinas em que os conjuntos de caracteres normais tinham apenas letras maiúsculas. A distinção entre maiúsculas e minúsculas nesses idiomas (pelo menos) é mais um artefato histórico do que uma escolha de design de idioma.

Agora, você pode argumentar que a insensibilidade a maiúsculas e minúsculas perdoa, mas o outro lado da questão é que a maiúsculas e minúsculas resulta em um código mais legível, porque ele cria o código para usar a capacidade de conexão do cliente.


4
Estou farto do argumento "X é bom, Y aplica coisa relacionada Z, portanto Y faz bem aplicando X" (por exemplo, estilo de codificação sã / regra de Python / impedimento). Nenhum bom programador capitaliza de maneira a afetar seriamente a legibilidade, mesmo quando permitido. Aqueles que abusam da insensibilidade a maiúsculas e minúsculas também capitalizam inconsistentemente em um ambiente sensível a maiúsculas e minúsculas (e cometem centenas de outras atrocidades), são forçados a usar a mesma capitalização ruim para cada uso de um nome individual. Programadores ruins podem escrever o Fortran em qualquer idioma. (Disclaimer: Eu sou um grande fã de maiúsculas e minúsculas!)

Adivinha. Estou cansado de ter que ler código escrito por programadores ruins que pensam que são tão bons programadores que podem desenvolver suas próprias regras de estilo únicas. (Disclaimer: eu aprendi a programa nos dias de Fortran e COBOL, e eu detesto insensibilidade caso e outras atrocidades linguísticas daquela época.)
Stephen C

Qualquer uso de maiúsculas em qualquer linguagem que não insista em caso constitui abuso de insensibilidade.
Kaz

@Kaz - erm ... tente dizer isso a um milhão de programadores SQL.
Stephen C

1

Sensibilidade ao caso considerada prejudicial.

A vida não diferencia maiúsculas de minúsculas e nem usuários ou programadores.

Linguagens que diferenciam maiúsculas de minúsculas são um acidente histórico, de sistemas restritos que dificultam comparações que diferenciam maiúsculas de minúsculas. Esse handicap não existe mais, portanto não há razão para criar um sistema de computador que diferencia maiúsculas de minúsculas.

Eu diria que a distinção entre maiúsculas e minúsculas é ruim , pois coloca a conveniência do computador antes da do usuário.

(Relacionado, lembro-me de alguns anos atrás, algum gênio se recusou a pagar a fatura do cartão de crédito porque seu nome estava em maiúsculas, mas ele a escreveu em letras maiúsculas e minúsculas. um pedido de pagamento válido.O juiz considerou o argumento como merecia).


A distinção entre maiúsculas e minúsculas não coloca a conveniência do computador antes da do usuário. Eu implementei linguagens com distinção entre maiúsculas e minúsculas e a única diferença é uma chamada de função adicional em alguns lugares. Além disso, outras respostas dizem que o caso em -sensibilidade é um artefato histórico devido a conjuntos de caracteres limitados - contradiz sua teoria, não é?

O Unicode coloca isso em um outro domínio.
DeadMG

3
Esse blog não justifica por que é ruim em C, apenas em Python ou PHP - e o OP não está falando sobre identificadores que diferenciam maiúsculas de minúsculas, apenas palavras-chave . Esse link não tem absolutamente nada a dizer sobre esse assunto.
DeadMG

1
Os editores do @Ben podem (e fazem) corrigir as letras maiúsculas e minúsculas enquanto você digita, independentemente das regras do idioma. Permitir erros que, no entanto, escapam (por exemplo, porque você não tem um editor sofisticado em mãos) não ajuda. Significa deixar um problema por aí, em vez de reclamar para corrigi-lo. Além disso, uma vez que eu uso letras maiúsculas consistentes, posso ter vários identificadores diferentes, mas denotando coisas muito diferentes e sendo fácil de analisar os seres humanos graças ao contexto e letras maiúsculas, sem ambiguidade.

2
@ Ben: Em alguns idiomas, existem costumes lexográficos muito rígidos, ou até regras. Em C e C ++, all-caps é uma macro e as macros devem permanecer all-caps para evitar confusão. Alguns idiomas têm significados diferentes para símbolos com ou sem maiúsculas iniciais (e eu não sei como eles se sairiam em vários idiomas que não têm letras maiúsculas e minúsculas correspondentes). Se você possui regras ou convenções como essa, obtém algo do efeito de diferentes espaços para nome, e a duplicação de nomes de identificador em diferentes espaços para nome geralmente funciona.
David Thornley

1

Da minha experiência pessoal, não vejo grande diferença entre idiomas sensíveis a maiúsculas e minúsculas.

O mais importante é o nome e as convenções estruturais que um programador deve manter em seu código e nenhum compilador ou analisador verifica isso por ele. Se você seguir algum tipo de regra, conhecerá facilmente um nome adequado (você não pensará se nomeou uma variável checkOut ou CheckOut) e seu código provavelmente será sensível a maiúsculas e minúsculas.

Não se deve usar CheckOut e checkOut e checkout e chEckOuT e CHECKOUT no mesmo significado. Isso prejudicará a legibilidade e tornará mais compreensível a compreensão desse tipo de código (mas há uma coisa pior que se pode fazer para destruir a legibilidade do código).

Se você usar algum tipo de regra, verá de relance, por exemplo:

CheckOut.getInstance () - é um método estático de uma classe chamada checkOut.calculate () - é um método de um objeto mantido em campo público ou variável chamado _checkOut.calculate () - é um método de um objeto mantido em um campo privado chamado CHECKOUT - é um campo / variável estático ou constante final

sem verificar alguns outros arquivos ou partes de um arquivo. Isso torna a leitura do código mais rápida.

Eu vejo muitos desenvolvedores usando regras semelhantes - em linguagens que eu frequentemente uso: Java, PHP, Action Script, JavaScript, C ++.

Em um caso raro, pode-se ficar zangado com a insensibilidade de maiúsculas e minúsculas - por exemplo, quando você deseja usar o CheckOut para um nome de classe e checkOut para uma variável e não pode, porque colide um com o outro. Mas é um problema de um programador usado para diferenciar maiúsculas de minúsculas e usá-lo em suas convenções de nomenclatura. Pode-se ter regras com prefixos padrão ou pós-correções em uma linguagem que não diferencia maiúsculas de minúsculas (não programa no VB, mas sei que muitos programadores do VB têm esse tipo de convenções de nomenclatura).

Em poucas palavras: eu vejo melhor a distinção entre maiúsculas e minúsculas (apenas para linguagens orientadas a objetos), porque a maioria dos desenvolvedores usa linguagens com distinção entre maiúsculas e minúsculas e a maioria deles usa convenções de nomenclatura com base na distinção entre maiúsculas e minúsculas. capaz de manter suas regras sem algum tipo de modificação. Mas é um argumento bastante religioso - não um objetivo (não se baseia em desvantagens reais ou em aspectos positivos da sensibilidade a maiúsculas e minúsculas) - porque não vejo nenhum quando se trata de um bom desenvolvedor, quando se trata de um bom desenvolvedor que se possa produzir código de pesadelo mesmo quando há distinção entre maiúsculas e minúsculas, por isso não é uma grande diferença).


1

Linguagens de programação não diferenciam maiúsculas de minúsculas.

A principal razão pela qual tantas línguas hoje em dia diferenciam maiúsculas de minúsculas é simplesmente um design de linguagem de culto à carga: "C fez dessa maneira, e C é incrivelmente popular, então deve estar certo". E, como em muitas outras coisas, C errou este, comprovadamente.

Na verdade, isso faz parte da filosofia de condução por trás de C e UNIX: se você tiver uma escolha entre uma solução ruim que é fácil de implementar e uma boa solução mais difícil de implementar, escolha a solução ruim e force o trabalho de contornar sua bagunça. o usuário. Isso pode parecer uma piada, mas é absolutamente verdade. É conhecido como o "pior é o princípio melhor" e tem sido diretamente responsável por bilhões de dólares em danos nas últimas décadas devido ao C e C ++, tornando muito fácil escrever softwares com falhas e inseguros.

Tornar uma linguagem sensível a maiúsculas e minúsculas é definitivamente mais fácil; você não precisa das tabelas lexer, parser e symbol para fazer o trabalho extra de garantir que tudo corresponda de uma maneira que não diferencia maiúsculas de minúsculas. Mas também é uma má ideia, por duas razões:

  • Primeiro, especialmente se você estiver criando uma linguagem de script, um simples erro de digitação em que você chama algo de "myObject" em um lugar e "MyObject" em outro, onde obviamente você está se referindo ao mesmo objeto, mas ficou um pouco inconsistente com a capitalização , não se transforma em um erro de tempo de execução. (Isso é famoso como um dos principais problemas nas linguagens de script que entendem errado, como o Python.)
  • Segundo, não ter distinção entre maiúsculas e minúsculas significa que não é possível abusar da distinção entre maiúsculas e minúsculas para que a mesma palavra se refira a duas coisas diferentes no mesmo escopo apenas alterando a capitalização. Se você já teve que trabalhar com o código do Windows em um ambiente C e executar declarações feias como HWND hwnd;, saberá exatamente do que estou falando. Pessoas que escrevem assim devem ser retiradas e filmadas, e tornar o idioma insensitivo a maiúsculas e minúsculas impede que o abuso de sensibilidade entre maiúsculas e minúsculas penetre no seu código.

Portanto, faça um esforço extra para acertar. O código resultante será mais limpo, mais fácil de ler, menos buggy e tornará seus usuários mais produtivos, e esse não é o objetivo final de qualquer linguagem de programação?


As linguagens de programação devem ter escopo lexical para detectar esse tipo de erro antes do tempo de execução (mesmo que sejam altamente dinâmicas). O Lisp comum é uma linguagem altamente dinâmica, mas os compiladores nos dizem quando usamos uma variável que não possui ligação lexical e não foi globalmente definida como uma variável dinâmica. Você não pode confiar na distinção entre maiúsculas e minúsculas para isso porque deseja capturar todos os erros de digitação, não apenas os que envolvem maiúsculas e minúsculas.
Kaz

Eu não me importo HWND hwnd;. Este é um exemplo em que a distinção entre maiúsculas e minúsculas funciona bem. A convenção "Indian Hill" do tipo "all caps" é boba. hwnd_t hwndé muito melhor. Eu suspeito que é tudo por causa de FILE. Era uma vez Versão 6 Unix tinha em seu O arquivo I / biblioteca cabeçalho este: #define FILE struct _iobuf. Foi em todas as letras maiúsculas, porque era uma macro. Quando se tornou um typedef no ANSI C, a ortografia em maiúsculas foi mantida. E eu acho que é por imitação deste que a convenção ALL_CAPS_TYPE foi inventado, e codificados no Guia de Estilo the Bell Lab "Indian Hill (o original!).
Kaz

Se você agora busca no "Indian Hill Style Guide", encontra principalmente referências a um documento de 1990 da Bell Labs, que se arrepende completamente de todos os nomes de maiúsculas e minúsculas: nenhum vestígio de tal recomendação. Mas a versão original recomendou coisas como typedef struct node *NODE. Tenho certeza de que é onde a Microsoft deve ter percebido isso. Então, culpe Bell Labs por HWND.
Kaz

1

Não acredito que alguém tenha dito "a distinção entre maiúsculas e minúsculas facilita a leitura do código".

Certamente não! Eu olhei por cima do ombro de um colega para variáveis ​​chamadas Empresa e empresa (variável pública Empresa, empresa variável privada combinada) e sua escolha de fonte e cor torna incrivelmente difícil diferenciar as duas - mesmo quando próximas uma da outra.

A declaração correta deve ser "maiúsculas e minúsculas facilita a leitura do código". Essa é uma verdade muito mais óbvia - por exemplo, variáveis ​​chamadas CompanyName e CompanyAddress, em vez de companyname. Mas nenhum idioma que conheço faz com que você use apenas nomes de variáveis ​​em minúsculas.

A convenção mais insana que conheço é a "pública em maiúscula, privada em minúscula". É só pedir problemas!

Minha opinião sobre os erros é "melhor que algo falhe ruidosamente e o mais rápido possível, em vez de silenciosamente falhe, mas pareça ter sucesso". E não há tempo de compilação.

Se você erroneamente usar uma variável em minúscula quando pretender usar maiúsculas, ela será compilada se você a estiver referenciando na mesma classe . Assim, você pode parecer bem-sucedido tanto no tempo de compilação quanto no tempo de execução, mas fazendo sutilmente a coisa errada e talvez não a detecte por um longo tempo. Quando você detecta que há algo errado

É muito melhor usar uma convenção em que a variável privada tenha um sufixo - por exemplo, variável pública da empresa, variável privada da empresaP. Ninguém vai acidentalmente misturar os dois, e eles aparecem juntos no senso comum.

Isso contrasta com uma objeção que as pessoas têm em relação à notação húngara, onde uma variável privada prefixada pCompany não apareceria em um bom lugar no intelecto.

Esta convenção tem todas as vantagens da terrível convenção em maiúsculas / minúsculas e nenhuma de suas desvantagens.

O fato de as pessoas sentirem a necessidade de apelar para a distinção entre maiúsculas e minúsculas para distinguir entre variáveis ​​mostra, na minha opinião, falta de imaginação e falta de bom senso. Ou, infelizmente, as ovelhas humanas gostam do hábito de seguir uma convenção porque "é assim que sempre é feito"

Torne as coisas com as quais você trabalha clara e obviamente diferentes entre si, mesmo que estejam relacionadas!


1
Ok então companyName == companyname. Isso parece razoável, mas como você lida com as localidades? A compilação do seu programa em diferentes partes do mundo causará diferentes semânticas, como ocorre no PHP? Você será totalmente anglo-centrado e suportará apenas o conjunto imprimível ASCII nos identificadores? Insensibilidade ao caso é muita complexidade extra para pouquíssimo ganho extra.
Phoshi

0

Você não deve introduzir insensibilidade ao caso sem uma boa razão para fazê-lo. Por exemplo, lidar com comparações de casos com Unicode pode ser uma chatice. A distinção entre maiúsculas e minúsculas (ou a falta dela) de idiomas mais antigos é imaterial, pois suas necessidades eram muito diferentes.

Os programadores nesta época esperam a distinção entre maiúsculas e minúsculas.


1
As comparações de casos não são tão difíceis. Apenas decomponha seus identificadores. É = E '= e' = é. Lembre-se de que você ainda pode escolher quais regras de caso seguir e o inglês é uma escolha razoável. (certamente, se as palavras-chave são o Inglês também)
MSalters

2
Sim, eles são "tão difíceis" em todo o espaço Unicode.
Kaz

1
"Os programadores nesta época esperam a distinção entre maiúsculas e minúsculas"? Somente se eles tiverem Síndrome de Estocolmo por terem trabalhado com a família C por muito tempo.
Mason Wheeler

Bem, a família C é responsável apenas por uma proporção muito grande de idiomas e códigos. Além disso, acho que é uma coisa boa e seu comentário não propõe nenhuma razão para que não seja.
DeadMG

0

A distinção entre maiúsculas e minúsculas torna o código mais legível e a programação mais fácil.

  • As pessoas acham o uso adequado de maiúsculas e minúsculas mais fácil de ler .

  • Permite / incentiva o CamelCase de modo que a mesma palavra em maiúsculas e minúsculas possa se referir a coisas relacionadas: Car car; Assim, a variável nomeada caré criada do tipo Car.

  • ALL_CAPS_WITH_UNDERSCORES indica constantes por convenção em vários idiomas

  • all_lower_with_underscores pode ser usado para variáveis ​​de membro ou qualquer outra coisa.

  • Todas as ferramentas de programação modernas (controle de fonte, editores, diff, grep, etc) são projetadas para diferenciar maiúsculas de minúsculas. Você sempre terá problemas com as ferramentas que os programadores dão como certa se você criar uma linguagem que não diferencia maiúsculas de minúsculas.

  • Se o idioma for interpretado, pode haver uma penalidade de desempenho para analisar o código sem distinção entre maiúsculas e minúsculas.

  • E os caracteres que não são do inglês? Você está decidindo agora nunca apoiar copta, chinês e hindi? Eu sugiro fortemente que você faça com que o seu idioma padrão seja tudo UTF-8 e que suporte alguns idiomas que tenham caracteres sem equivalente em maiúsculas ou minúsculas. Você não usará esses caracteres em suas palavras-chave, mas quando começar a desativar a distinção entre maiúsculas e minúsculas em várias ferramentas (para encontrar coisas nos arquivos, por exemplo), terá algumas experiências surreais e provavelmente desagradáveis.

Qual o benefício? Os três idiomas mencionados são da década de 1970 ou anterior. Nenhuma linguagem moderna faz isso.

Por outro lado, qualquer coisa que realmente faça o usuário final feliz traz um pouco de luz ao mundo. Se isso realmente afetar a felicidade do usuário, você deverá fazê-lo.

Se você quiser simplificar para os usuários finais, pode fazer melhor do que a sensibilidade / insensibilidade ao caso - dê uma olhada no Scratch ! Menos gatos dos desenhos animados e cores mais amigáveis ​​para os negócios, e você tem a linguagem mais amigável que eu já vi - e você não precisa escrever nada! Apenas um pensamento.


1
Eu acho que você queria dizer "a distinção entre maiúsculas e minúsculas é um pesadelo". O japonês tem caso: hiragana e katakana são, tipo, casos diferentes. Assim como A e a são "iguais" de certa forma, também são あ e ア. Às vezes, o katakana é usado para dar ênfase, com letras maiúsculas nas línguas que usam o alfabeto romano. Desnecessário dizer que seria idiotice tratar hiragana e katakana como os mesmos em identificadores de linguagem de programação.
25412 Kaz

Obrigado - isso é enriquecedor! Limpei minha postagem um pouco.
precisa saber é o seguinte

1
Car car;é um dos melhores argumentos contra a distinção entre maiúsculas e minúsculas: é feio e, se seu idioma não diferencia maiúsculas de minúsculas, você não pode abusar dessa diferenciação.
Mason Wheeler

1
É Car myCar;muito melhor?
precisa saber é o seguinte

@Mason Wheeler: Se limitarmos nossas construções de linguagem àquelas que não podemos abusar, não seremos capazes de fazer muito, não é? Meu conselho para quem abusar da distinção entre maiúsculas e minúsculas é "Não".
David Thornley
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.