17

Possibili duplicati:
Is there any advantage of being a case-sensitive programming language?
Why are many languages case sensitive?Qual è lo scopo della distinzione tra maiuscole e minuscole nelle lingue?

Qualcosa mi sono sempre chiesto, è il motivo per cui sono lingue progettati per essere case sensitive?

Il mio cervello di pisello non è in grado di capire perché sia ​​utile.

Ma sono sicuro che ce n'è uno là fuori. E prima che qualcuno lo dica, avere una variabile chiamata dog e Dog differenziata dalla distinzione tra maiuscole e minuscole è davvero una cattiva pratica, giusto?

Eventuali commenti apprezzati, insieme forse a qualsiasi storia in materia! Non sono generalmente sensibile alla distinzione tra maiuscole e minuscole, ma sensibile alla sensibilità intorno alla distinzione tra maiuscole e minuscole, quindi teniamo tutte le risposte e i commenti civili!

+1

La maiuscole/minuscole rende tutto più facile da leggere ... Anche se non correlato al caso ma guarda all'indentazione; linguaggi come Python hanno successo a causa di "indentazione" che può in un certo senso essere case sensitive. –

+2

Il mio modo di vedere è che tutti i micro benefici di questo sono superati di gran lunga dai negativi di missuse, debugging ecc. –

+1

@ Tom: Diciamo che hai una classe chiamata PIT, e hai un const chiamato TAX ... O se hai una variabile regolare di nome hEllO. –

risposta

17

Non è necessariamente una cattiva pratica avere due membri differenziati per caso, in lingue che lo supportano. Ad esempio, ecco un po 'abbastanza comune di C#:

private readonly string name; 
public string Name { get { return name; } } 

Personalmente sono molto felice con la sensibilità caso - in particolare in quanto consente il codice come sopra, dove la variabile membro e le convenzioni Segue Proprietà in ogni caso, per evitare confusione.

noti che maiuscola ha un aspetto cultura troppo ... non tutte le colture saranno ritengono gli stessi caratteri equivalenti ...

+0

Grazie per la risposta, potresti ampliare l'aspetto culturale? Non sono sicuro di aver capito appieno. –

+4

L'esempio più spesso dato è le varianti turche di "I". L'insensibilità alla causa inglese è insensibile a questo, perché "i" =/= "I" in questo caso. – maxwellb

+3

+1 Jon, perché anch'io appoggio le mie proprietà con nomi di caratteri minuscoli. Personalmente non mi piace usare i prefissi "_" per i campi privati. – maxwellb

3

Immagina di avere un oggetto chiamato dog, che ha un metodo chiamato Bark(). Inoltre hai definito una classe chiamata Dog, che ha un metodo statico chiamato Bark(). Scrivi dog.Bark(). Quindi cosa farà? Chiama il metodo dell'oggetto o il metodo statico dalla classe? (in una lingua in cui non esiste ::)

+3

Perché non chiamarli cose diverse in modo da non essere confusi più avanti? Avere una classe chiamata Cane e un oggetto chiamato cane si confonderà. Questo è quello che non capisco. –

+2

Il cane è troppo generico ... Un oggetto di Dog come labrador avrebbe più senso. –

+3

Così ora il compilatore sa quale metodo chiamare, ma il lettore sarà ancora confuso. Penso che dovresti usare qualcosa di meglio per distinguere tra i due rispetto alla maiuscola di 1 lettera. – Miel

1

confronto Case-sensitive è (da un punto di vista naive che ignora canonica equivalenza) banale (basta confrontare i punti del codice), ma il confronto insensibile alle maiuscole e minuscole non è ben definito ed estremamente complesso in tutti i casi, e le regole sono impossibili da ricordare. L'attuazione è possibile, ma inavvertitamente porterà ad un comportamento inaspettato e sorprendente. A proposito, alcune lingue come Fortran e Basic sono sempre state insensibili al maiuscolo/minuscolo.

+1

Penserei che il confronto "sensibile" del caso sarebbe più banale. Come si fa a "confrontare i codici" per dire che "a" ~ "A"? Nella codifica di un personaggio, si può confrontare caso sensibilmente facendo un semplice confronto binario ... – maxwellb

+1

Ho confuso la case-sensibilità con insensibilità alle maiuscole. – Philipp

+0

Ogni utente che abbia mai utilizzato può effettuare ricerche senza distinzione tra maiuscole e minuscole. Molti (ad esempio: Emacs) lo fanno per impostazione predefinita. Sì, le cose si confondono quando si hanno a che fare con lingue diverse dall'inglese, ma fintanto che le regole per il compilatore e il ricercatore sono le stesse, non ci sono problemi reali lì. –

2

Sono sicuro che originariamente era una considerazione prestazionale. Convertire una stringa in maiuscolo o minuscolo per il confronto senza memoria non è un'operazione costosa, ma non è nemmeno libera, e sui vecchi sistemi potrebbe aver aggiunto una complessità che i sistemi del giorno non erano pronti a gestire.

E ora, naturalmente, i linguaggi amano essere compatibili l'uno con l'altro (per esempio, VB non può distinguere tra classi C# o funzioni che differiscono solo nel caso), le persone sono abituate a nominare lo stesso testo ma con differenti casi (vedi la risposta di Jon Skeet - Lo faccio molto), e il valore dei linguaggi incurabili non è stato sufficiente per superare questi due.

+2

Sono altrettanto sicuro che originariamente non aveva nulla a che fare con le prestazioni che il caso veniva ignorato nei linguaggi di programmazione. Piuttosto, erano gli schemi di codifica a 5 bit usati su (molti) teleprinters degli anni '50, che semplicemente non avevano lettere maiuscole e minuscole. NON SERVE MAIUSCOLE O PUNTEGGIO IN UN TELEGRAM STOP –

+1

Penso che contenga la teoria delle prestazioni che i linguaggi insensibili alle maiuscole e minuscole come Fortran e Basic sono tra i più antichi di tutte le lingue. – Philipp

+1

Heh, Philipp vince. Non ci ho nemmeno pensato. –

8

Uno dei principali motivi di distinzione tra maiuscole e minuscole nei linguaggi di programmazione è la leggibilità. Anche le cose che significano lo stesso dovrebbero apparire uguali.

ho trovato la seguente interesting example di M. Sandin in una discussione correlati:

ho usato per credere sensibilità caso è stato un errore , fino a quando ho fatto questo nel caso lingua insensitive PL/SQL (sintassi ora entierly dimenticato):

function IsValidUserLogin(user:string, password :string):bool begin 
    result = select * from USERS 
      where USER_NAME=user and PASSWORD=password; 
    return not is_empty(result); 
end 

Questo passata inosservata per diversi mesi su una produzione a basso volumeSistema, e nessun danno ne è derivato. Ma è un insetto insidioso, insensibilità del caso , convenzioni di codifica e il modo in cui gli esseri umani leggono il codice. La lezione per me era questa: le cose che sono la stessa dovrebbero apparire uguali.

Riesci a vedere il problema immediatamente? Non potevo ...

+4

Questo è il codice che fa distinzione tra maiuscole e minuscole, quindi 'PASSWORD = password' è sempre vero. – Blorgbeard

+1

@Tom Gullen: è spiegato [più in basso] (http://lambda-the-ultimate.org/node/1114#comment-12098) nella discussione collegata. –

+1

la mia ipotesi? PASSWORD = la password è sempre valida? Quindi qualsiasi nome utente valido accederà ... almeno se ho ragione: P –

9

Mi piace la distinzione tra maiuscole e minuscole per distinguere tra classe e istanza.

Form form = new Form();

Se non è possibile farlo, si finisce con le variabili chiamate myForm o form1 o f, che non sono più pulito e descrittivo pianura vecchio form.

Sensibilità alle maiuscole e minuscole significa anche che non si dispone di riferimenti a form, FORM e Form che significano tutti la stessa cosa. Trovo difficile leggere questo codice. Trovo molto più facile scansionare il codice in cui tutti i riferimenti alla stessa variabile appaiono esattamente uguali.

+1

Avendo lavorato molto nelle lingue maiuscole e minuscole, ho scoperto che inventare nomi diversi per classi e oggetti è una buona abilità da acquisire. –

+1

Questo problema non appare ad es. Visual Basic perché identificatori di tipi e identificatori di oggetti sono chiaramente separati lì ('Dim form As Form' ecc., Solo i tipi possono apparire dopo' As'). Di nuovo è la sintassi C che è difettosa, non l'idea in generale. – Philipp

+3

@ T.E.D. Dipende.A volte è il nome più ovvio e utile - a volte non lo è. È bello avere almeno l'opzione. –

2

Il motivo per cui non riesci a capire perché la case-sensitive sia una buona idea, è perché non lo è. È solo una delle strane stranezze di C (come gli array basati su 0) che ora sembrano "normali" perché così tante lingue hanno copiato ciò che C ha fatto.

C utilizza la distinzione tra maiuscole e minuscole in indentificatori, ma da una prospettiva di progettazione linguistica è stata una scelta strana. La maggior parte delle lingue progettate da zero (senza alcuna considerazione di essere "come C" in alcun modo) sono state rese insensibili alle maiuscole e minuscole. Questo include Fortran, Cobol, Lisp e quasi l'intera famiglia di lingue Algol (Pascal, Modula-2, Oberon, Ada, ecc.)

Le lingue di scripting sono un miscuglio. Molti sono stati resi sensibili alla distinzione tra maiuscole e minuscole perché il filesystem di Unix era sensibile al maiuscolo e al minuscolo e hanno dovuto interagire sensibilmente con esso. C è cresciuto in modo organico nell'ambiente Unix e probabilmente ha raccolto la filosofia sensibile al maiuscolo/minuscolo da lì.

+0

I computer erano molto meno potenti negli anni '70 di quanto lo siano oggi; ma mi chiedo se forse non è stato un caso di ottimizzazione prematura 40 anni fa. –

+0

L'intero linguaggio C potrebbe essere visto in quel modo. Ad esempio, gli incrementi e i decrementi di pre e post sono stati consacrati come operatori perché la CPU C originale (CISC) aveva varianti opcode per la maggior parte delle operazioni. –

4

Qualcosa che mi sono sempre chiesto, è perché le lingue sono progettate per essere case sensitive?

In definitiva, è perché è più facile implementare correttamente un confronto case-sensitive; confronti solo byte/caratteri senza alcuna conversione. Puoi anche fare altre cose come l'hashing davvero facile.

Perché questo è un problema? Bene, l'insensibilità alle maiuscole e minuscole è piuttosto difficile da aggiungere a meno che tu non sia in un piccolo dominio di caratteri supportati (in particolare, US-ASCII).Le regole di conversione dei casi variano in base alla locale (le regole turche non sono le stesse di quelle nel resto del mondo) e non c'è alcuna garanzia che il flipping di un singolo bit faccia la cosa giusta, o che sia sempre lo stesso bit e sotto lo stesso precondizioni. (IIRC, ci sono alcune regole davvero complesse in alcune lingue per buttare via i segni diacritici quando si convertono le vocali in maiuscole e reintrodurle quando si converte in minuscole.Mi dimentico esattamente quali sono i dettagli.)

Se sei sensibile al maiuscolo/minuscolo , ignori tutto questo; è solo più semplice. (Si badi bene, è comunque necessario prestare attenzione ai moduli di normalizzazione UNICODE, ma questa è un'altra storia e applica tutte le regole del caso che si stanno utilizzando.)

+1

Anche essere contento che nessuno ha automatizzato l'intestazione del titolo per i linguaggi del computer (e in realtà non sono sicuro di come funzionerebbe); le regole per * that * sono molto più complesse! –

Problemi correlati