Por que caso muitas línguas sensível?

StackOverflow https://stackoverflow.com/questions/503218

  •  20-08-2019
  •  | 
  •  

Pergunta

Por que caso muitas línguas sensível?

É simplesmente uma questão de herança? C ++ é sensível a maiúsculas porque C é, Java é sensível a maiúsculas porque C ++ é, etc.? Ou há uma razão mais pragmática por trás disso?

Foi útil?

Solução

Unix.

Unix era maiúsculas e minúsculas, e assim por muitas linguagens de programação desenvolvidas para uso em Unix eram maiúsculas de minúsculas.

Os computadores não estão perdoando - um carácter maiúsculo não é a mesma coisa que um caractere minúsculo, eles são completamente diferentes. E de volta ao processar ciclos, RAM e assim por diante foram caros não foi visto como vale a pena o esforço para compiladores de força e computadores a serem "perdoar", as pessoas estavam apenas tentando obter as coisas para o trabalho.

Observe como caso insensibilidade realmente não se tornar algo útil até coisas como Visual Basic veio junto - uma vez que as empresas começaram a ficar investido no conceito que a obtenção das massas para o programa era uma coisa boa para sua linha de fundo (ou seja, a Microsoft ganha mais dinheiro se há mais programas no Windows) fez as línguas começam a ser mais amigável e mais indulgente.

Outras dicas

Eu não acho que você vai obter uma resposta melhor do que "porque o autor (s) de que a linguagem pensei que era melhor assim". Pessoalmente, acho que eles estão certos. Eu odiaria encontrar essas linhas em qualquer lugar do mesmo arquivo de origem (e se referem ao mesmo método de objeto +) ... 

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

Eu não acho que ninguém ficaria feliz em ver este ...

Uma coisa interessante a considerar é que o Inglês também é case-sensitive. (Eu suspeito que isso é verdade para a maioria das línguas naturais, mas também não pode ser verdade para todos.)

Há uma grande diferença (onde eu vivo, de qualquer maneira, perto da cidade de Reading) entre:

Eu gosto de ler.

e

Eu gosto de ler.

Da mesma forma, enquanto muitas pessoas do capitalizar incorretamente, e, geralmente, você pode entender o que se entende, isso não significa que tal escrita é considerado correta . Eu sou um defensor quando se trata deste tipo de coisa, o que não quer dizer que eu acertar tudo eu mesmo, é claro. Eu não sei se isso é parte da herança de programação sensibilidade caso da linguagem, mas eu suspeito que seja.

Uma vantagem distinta de maiúsculas e minúsculas para linguagens de programação é que o texto torna-se culturalmente insensível bem. É ruim o suficiente ter que soletrar ocasionalmente para um compilador que codificação de texto é usado para um arquivo de origem - ter que especificar quais Cultura está em seria ainda pior: (

Na verdade, é extremamente prático, tanto para o desenvolvedor e para a especificação de sintaxe da linguagem:. Baixa / case distinção superior adiciona uma grande quantidade de expressividade para identificador de nomenclatura

Do ponto de vista da sintaxe da linguagem, você pode forçar certos identificadores de começar com uma maiúscula ou minúscula (por exemplo, nome da classe Java). Isso faz com que a análise mais fácil e, portanto, ajuda a manter a sintaxe limpa.

Do ponto de vista do desenvolvedor, isso permite um grande número de convenções de codificação convenientes, tornando seu código mais claro e mais fácil de entender.

Meu palpite seria que a sensibilidade caso amplia o espaço de nome. Um truque bom como 

MyClass myClass;

seria impossível com o compilador de maiúsculas e minúsculas.

Caso de dobramento só é simples em Inglês (e para todos os caracteres <128). A sz ou "sharp s" (SS) não tem uma letra maiúscula variante no conjunto de caracteres 8859-1 ISO. Ele recebeu apenas um em Unicode após cerca de um década de discussão (e agora, todas as fontes devem ser atualizados ...). Kanji e Hiragana (alfabeto japonês) nem sei minúsculas.

Para evitar esta confusão, mesmo nesta época de Unicode, não é sensato deixar que caso dobrar e identificadores Unicode.

Voltar ao analisar e compilação era real caro e levaria toda a noite era vantajoso para o compilador se ele não tem que se preocupar caso.

Uma vez identificadores veio à existência que só estavam única via seu caso tornou-se muito difícil para voltar. Muitos desenvolvedores gostou e não parece ser um grande desejo de desfazê-lo.

ExpertSexChange

Eu acredito que este é um concorrente para Stack Overflow onde você tem que pagar para ler as respostas. Hmm ... com caso insensibilidade, o significado do nome do site é ambíguo.

Esta é uma boa razão para línguas sendo maiúsculas de minúsculas. Menos ambigüidade! Ambigüidade para os programadores é considerado nojento.

sensibilidade caso contribui para a legibilidade linguagem pelo uso de convenções de nomenclatura. Você não pode escrever 

Person person = new Person("Bill");

Se seu idioma é maiúsculas e minúsculas, porque o compilador não seria capaz de distinguir entre o nome da classe eo nome da variável.

Além disso, ter Pessoa, pessoa, pessoa, pessoa, por pessoa, todas as fichas ser equivalentes iria me dar uma dor de cabeça. :)

O que é a forma de capital de i ? I (U + 0049) ou i (U + 0130)?

A capitalização é locale dependente.

Muitos (não-programação) línguas (por exemplo europeia utilizando o alfabeto romano) são case-sensitive, por isso é natural para falantes nativos dessas línguas para usar maiúsculas / minúsculas distinções-.

A própria idéia de que linguagens de programação que não ser case-sensitive é um artefato histórico decorrente das limitações de hardware início de geração (incluindo máquinas de teletipo pré-computador que usavam um personagem 5-bit código).

As pessoas que defendem línguas case-cegos deve ser incapaz de distinguir 

IAmNowHere

de 

IAmNowhere

( É uma piada ; -)

Porque eles são como mudo como uma caixa de rãs , precisamente pelas razões dadas para o ponto de vista oposto neste segmento (eu não sou mesmo vou perguntar do que se trata. Madeira para as árvores e tudo o que).

Quando FOOBAR = FooBar = foobar, você começa a escolher sua convenção, e outros programadores podem fazer o mesmo se eles compartilham sua preferência ou não . Sem confusão.

Eles também não podem fugir com o golpe de génio que está tendo uma constante, função e variável todos com o mesmo nome no mesmo arquivo, embora com diferentes caps. Mais uma vez, nenhuma confusão.

Você chamar seu website variável, que eles chamam site deles, e que o sistema fica confuso? Não é uma presa fácil, quer, quando você está digitalizando.

Como para pesquisas, que é realmente muito mais processamento para converter o nome em minúsculas antes de olhar-lo? Fazendo seu próprio otimização prematura é uma coisa, esperando que a partir do desenvolvedor do seu idioma de escolha é um outro nível de perder o ponto.

... e, no entanto, todas essas respostas dizendo maiúsculas e minúsculas reduz a confusão. Sigh

Há também Common Lisp, que é uma linguagem case-sensitive que muitas pessoas acreditam erroneamente que é case-insensitive. Quando você digita (car x) para o ouvinte, ele se transforma em (CAR X) para processamento. É possível definir símbolos com nomes minúsculas, mas eles têm de ser citado com algo como |lower-case-symbol|. Portanto, digitando (car x) ou (CAR X) ou (Car X) tudo funciona da mesma.

(Franz Lisp estava em um ponto introduzindo o que eles chamaram de capitalização "moderno", em que o ouvinte não iria dobrar casos, e CL palavras-chave seria em letras minúsculas. Eu nunca seguiu-lo bem o suficiente para saber o que aconteceu lá.)

A maiúsculas de uma carta não é um conceito universal. Java usa Unicode, por isso, se você queria case-insensitive Java, o significado de seu programa poderia mudar dependendo do que locale foi compilado.

A maioria das linguagens não deixe que você colocar pontos ou vírgulas (ou apóstrofo ou espaços) no meio de literais inteiros, provavelmente porque isso é também locale-dependente.

De Guia do .NET Framework Developer Convenções de Capitalização , Case-Sensibilidade:

Existem as diretrizes de capitalização apenas para fazer identificadores mais fácil ler e reconhecer. Caixa não pode ser utilizado como um meio de evitar nome colisões entre elementos da biblioteca.

Não assuma que toda a programação linguagens são case-sensitive. Eles são não. Os nomes não podem diferir em caso sozinho.

Como você gritar se você não tem CAPS ?! AHHH!

Você tem que ser expressivo. Mas com toda a honestidade, de todas as pessoas no mundo, aqueles que trabalham com a lógica de programação seria o primeiro a insistir que as diferenças estão em diferenças fatos.

sensibilidade

Caso realmente não ajuda caso consistência. 

Foo.Bar  
foo.Bar  
fOO.bAR

Em uma linguagem insensível caso que pode ser corrigido automaticamente pelo editor facilmente. Em uma fixação linguagem sensível caso, é mais difícil que seja legal. O editor primeiro tem a ckeck se foo.Bar e fOO.bAR existem e também tem de adivinhar que você digitou com o caso errado, em vez de se esquecer de declarar a variável (como Foo é diferente para foo).

Muitas pessoas aqui disseram que seria ruim para várias formas de capitalização para se referir à mesma coisa, por exemplo:. 

person
perSoN
PERSON

O que seria realmente ruim é se estes todos referidos objetos diferentes em código. Se você tem variáveis ??pessoa, pessoa ea pessoa todos referentes a coisas diferentes, você tem um problema.

Cada exemplo que eu vi apoiar sensibilidade caso é baseado em um desejo de má escrita, código undescriptive. por exemplo. a "data" vs. argumento "myDate" - estes são ambos igualmente undescriptive e más práticas. Uma boa prática é nomeá-lo o que ele realmente é: data de nascimento, HireDate, invoiceDate, qualquer que seja. E quem em sã consciência iria querer escrever código como: 

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

Por incrível que pareça este é perfeitamente válida caso em código VB.Net sensível. O pensamento de que maiúsculas e minúsculas permite ainda mais flagrante desobedecer boas práticas de programação é um argumento contra ela, não para ele.

Uma vez que muitas pessoas acham employeeSocailSecurityNumber tão legível como employee_social_security_number e é mais curto.

Eu acho que ter uma linguagem case-sensitive incentiva as pessoas a escrever pobre código. 

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

Duh. Você não poderia pensar em um nome de variável melhor do que "ShoeSize" para os diferentes propósitos? Há um bilhão de palavras diferentes que você pode usar, mas você optar por continuar a usar ShoeSize vez?

E você também pode (tolamente) é só usar single-letras ( "a" e "b" e "c") para todas as classes, variáveis, funções e métodos.

Mas Por que você iria querer?

Use nomes que fazem sentido , não: 

function a(a)
{
    int a = a.a;
    return a
}

Há uma outra razão línguas são maiúsculas de minúsculas. IDs podem ser armazenadas em uma tabela hash e tabelas de hash são dependentes de hash funções que lhe dão diferentes hashes para diferentes caso. E pode não ser conveniente para converter todos os IDs a todos superior ou a totalidade inferior antes de executá-los através da função hash. Me deparei com este problema quando eu estava escrevendo meu próprio compilador. Era muito mais simples (mais preguiçosos) para declarar a minha língua como maiúsculas e minúsculas.

Eu li toda esta discussão. Devo acreditar que aqueles que o relatório ter encontrado o valor de sensibilidade caso nunca programou em uma verdadeira linguagem de alto nível (que por definição é case insensitive). K & R admitir que C é de nível médio. Depois de programar em Pascal, Delphi, Lázaro, ADA, etc, aprende-se que o código altamente legível é simples de escrever e começar a correr rapidamente, sem ficar obcecado sobre concisas construções sensíveis caso. Afinal, a legibilidade é a primeira e última palavra sobre o assunto. Código é escrito para o ser humano, e não o computador. Sem problemas para depuração com código insensível caso. Quando se desce a uma linguagem de nível médio, encontra-se de que não existem vantagens em maiúsculas e minúsculas. Existem, no entanto, um número considerável de horas passadas a depuração sensibilidade caso causou problemas. Especialmente quando patching módulos em conjunto de diferentes codificadores. Parece também que um grande número de respondentes não entender o que se entende por caso insensibilidade. Apenas os caracteres a-z são afectadas. Estes são um subconjunto sequencial de caracteres ASCII. Três ou quatro bytes de código de máquina fazer o indiferente compilador para os casos neste intervalo de caracteres. Não altera sub-bar, numerais, ou qualquer outra coisa. Os pontos sobre outros idiomas e conjuntos de caracteres simplesmente não se aplicam a esta discussão. O compilador ou interruptor seria codificado para converter temporariamente ou não converter o caractere para análise em tempo de compilação com base no ser ASCII ou não.

Estou chocado com as novas linguagens como Python que saíram repetir o erro que K & R feitas. Sim, eles salvo meia dúzia de bytes em um ambiente onde a RAM total para compilador, fonte e código objeto era 1000 bytes. Isso foi antes. Agora memória não é um problema. Agora, sem nenhuma razão sensata, até mesmo as palavras de reserva em Python são sensíveis! Eu acho que não vai precisar usar "Para" de "Imprimir" como variável ou nome da função. Mas essa possibilidade foi preservada pela cara do tempo gasto contentando com o interruptor sobre o caso exato de cada identificador. Um mau negócio, eu acho.

A coisa mais próxima eu li até agora em apoio da sensibilidade caso é os comentários sobre hashing. Mas esses eventos codificação raros que podem ser tratadas com cuidadosa atenção aos detalhes não parecem ser para valer a pena o escrutínio inútil um codificador deve usar o código sensível caso de gravação. Duas visões do problema. Uma incentiva má codificação, armadilhas no código, e requer atenção extra a ser desviados a partir de conceitos maiores. O outro não tem lado negativo, tem funcionado na perfeição em linguagens de alto nível, e permite flexibilidade eram não faz mal. Ele olha para mim como mais um caso de VHS vitórias sobre BETA. É apenas a minha dois centavos aqui.

A aprendizagem é sempre mais fácil por exemplo então aqui vai:

C # (caso sensível mas utilizável a partir VB.NET que é insensível a maiúsculas): 

CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName      // Readable in both case sensitive and insensitive languages
_classMember   // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName   // Same style in case sensitive and insensitive languages
localVariable  // Never using prefix

Java e JS usar um estilo semelhante ao C #, mas os métodos / funções / eventos são declarados como variáveis ??doSomething, onEvent.

ObjectPascal (Delphi e Lazarus / FPC são maiúsculas e minúsculas, como ADA e VB.NET) 

CConstantName     // One can use Def or no prefix, not a standard
IInterfaceName
TClassName        // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer      // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable    // Older code uses prefix for parameters not local vars

usando apenas OneCase e prefixos para cada tipo faz sentido em todas as línguas. línguas Mesmo que começaram sem prefixos têm construções mais recentes, como Interfaces que não dependem de caso, mas usar um prefixo vez.

Portanto, não é realmente importante se uma língua é sensível a maiúsculas ou não. conceitos mais recentes foram adicionados às línguas sensíveis de casos que foram muito confuso para ser expresso por caso sozinho e necessária usando um prefixo.

Desde caso linguagens sensíveis começaram a usar prefixos, é apenas razoável para parar de usar caso com o mesmo nome identificador someIdentifier SomeIdentifier SOME_IDENTIFIER, ISomeIdentifier e apenas prefixos de uso em que faz sentido.

Considere este problema: Você tem um membro da classe chamada algo, um parâmetro chamado método / função de alguma coisa e uma variável local chamado de algo, o que convenção caso poderia ser usado para facilmente diferenciar entre estes? Não é mais fácil simplesmente usar o mais ConsistentCaseStyle em todos os lugares e adicionar um prefixo?

Fãs de casos línguas insensíveis se preocupam com a qualidade do código, eles só querem um estilo. Às vezes, eles aceitar o fato de que uma biblioteca é mal escrito e usar um estilo rigoroso enquanto a biblioteca pode ter nenhum estilo ou código pobres.

Tanto caso linguagens sensíveis e insensíveis exigem disciplina rigorosa, faz mais sentido ter apenas um estilo em todos os lugares. Seria melhor se tivéssemos uma linguagem que utilizou apenas StrictCase, um estilo em todos os lugares e prefixos.

Há um monte de código C pobres, sensibilidade caso não torná-lo legível e você não pode fazer nada sobre isso. Em uma linguagem insensível caso, você poderia aplicar um bom estilo em seu código sem reescrever a biblioteca. Em uma linguagem StrictCase que não existe ainda, todo o código teria qualidade decente:)

parece que as pessoas maioria deles concorda que a sensibilidade caso é importante e eu concordo.

No entanto, pode ser irritante quando você tem que digitar algo no caso correto, então eu acho que o IDE deve deixar você digita no caso errado, mas se você bater o atalho de auto-completar que deve fazer caso correspondência insensível. Isso nos dá o melhor de dois mundos.

Por padrões de codificação típicos, Pessoa seria uma classe, pessoa um nome de variável, e PESSOA uma constante. Muitas vezes é útil usar a mesma palavra com diferentes capitalização para significar algo relacionado mas ligeiramente diferente.

Então, se você tinha três funcionários em sua empresa todos chamados Robert, você referir a eles como Robert, Robert e seria ROBERT você? E confiar em que as pessoas saibam exatamente qual você quis dizer?

Dê-lhes endereços de email, como Robert@widgets.com, robert@widgets.com e ROBERT@widgets.com se o seu sistema de e-mail foi sensível a maiúsculas?

O potencial de uma violação não autorizada de dados pessoais seria enorme. Sem mencionar se você enviou a senha de root banco de dados para o empregado descontente prestes a ser demitido.

É melhor chamá-los de Bob, Robbie, e Robert. Melhor ainda chamá-los de Robert A, Robert B e Robert C se seus sobrenomes eram por exemplo Arthur, bancos e Clarke

Realmente - porque na terra tem uma convenção de nomenclatura que convida os erros ou confusão, que depende das pessoas serem muito alerta? Você é tão curto de palavras volcabulary?

E, como para a pessoa que menciona o truque supostamente útil "MyClass myClass" - por que, por quê? Você deliberadamente torná-lo difícil de ver de relance se um método utilizado é um método de classe ou um método de instância.

Além disso, você perdeu a chance de dizer a próxima pessoa que lê o seu código mais sobre o caso particular da classe.

Por exemplo.

Cliente PreviousCustomer

Cliente NewCustomer

Cliente CorporateCustomer

As suas necessidades de nomes de instância para idealmente dizer ao seu colega mais do que apenas a classe é baseado em!

Se a separação palavra não é importante, então por que colocar espaços entre as palavras? Portanto, eu acho que sublinhados entre as palavras em um nome de fazer aumentar a legibilidade. caso também inferior com Capitalização de caracteres apropriados é mais fácil de ler. Por último, é certamente muito mais fácil se todas as palavras pode ser transmitida de boca em boca - "Corporação Sublinhado Cliente" em vez de "Capital Minúsculas C o r p o r a t e Sublinhado Capital C Minúsculas u s t a s r"! - o primeiro pode ser falado 'em sua cabeça' o último não pode - eu me pergunto como as pessoas que estão felizes com alça de sensibilidade caso estes nomes sensíveis caso em seus cérebros - Eu realmente luta. Então, eu sinto que a sensibilidade caso não é de todo útil -. Um passo retrógrado de COBOL na minha opinião

Porque as pessoas as coisas a sério overthink.

Caso insensibilidade funciona melhor quando é também caso de preservação e combinado com uma separação entre o tipo e namespaces variáveis. Isso significa que:

  • Se você declarar uma classe como 'TextureImage' e, em seguida, tentar usá-lo como 'textureImage', o IDE pode corrigir automaticamente você. Isso lhe dá a vantagem de que você nunca terá que bater a tecla shift menos que você está declarando um identificador ou usando um sublinhado.

  • Assim como em Java e várias outras línguas; é perfeitamente válido para o tipo de "MyClass myClass". O IDE e o compilador deve ter nenhum problema de diferenciação entre o uso de um tipo eo uso de uma variável.

Além disso, garantias caso insensibilidade que 'o' e 'O' nunca se referem a diferentes objetos. argumentos comuns incluem:

  • "sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => e que alguém vai _Nunca_ ser autorizados a participar de uma equipe de programação, de modo que este é um argumento de pipoqueiro. mesmo se eles não conseguem fazê-lo, caso insensibilidade é mais a solução do problema, porque isso significa que você não tem que se lembrar qualquer combinação louca maiúsculas / minúsculas que eles usam.

  • "Você não pode Internacionalizar caso insensibilidade facilmente!"; => mais de 95% das linguagens de programação são escritos em Inglês para uma razão muito boa. não há codificação de caracteres concorrentes e a grande maioria dos teclados na terra são baseadas Inglês (em parcial ou total). apoiar identificadores Unicode é talvez a mais estúpida idéia de que alguém tenha veio com no século 21; porque uma parcela boa de caracteres Unicode são frikkin surragates invisíveis, leitura de código é forte o suficiente sem ter que usar o Google Translate, e escrevendo código é forte o suficiente sem ter que copiar e colar identificadores ou usar um mapa de caracteres.

  • "Mas o caso linguagens sensíveis têm mais identificadores!"; => Não, eles têm gramaticalmente identificadores sobrecarregado, o que é substancialmente pior.

Não uso nenhum línguas maiúsculas e minúsculas, mas as vantagens são por demais evidente se você pensar sobre esse tipo de coisa a sério.

A resposta razoável pode ser que os designers da linguagem pensei que tornaria a língua mais fácil de entender o pensamento sobre o futuro:)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top