Perché molte lingue fanno distinzione tra maiuscole e minuscole?

https://stackoverflow.com/questions/503218

20-08-2019
|

Domanda

È semplicemente una questione di eredità? C ++ distingue tra maiuscole e minuscole perché C è, Java distingue tra maiuscole e minuscole perché C ++ lo è, ecc.? O c'è una ragione più pragmatica dietro di essa?

Soluzione

Unix.

Unix faceva distinzione tra maiuscole e minuscole, e così tanti linguaggi di programmazione sviluppati per l'uso su Unix facevano distinzione tra maiuscole e minuscole.

I computer non perdonano: un carattere maiuscolo non è la stessa cosa di un carattere minuscolo, sono completamente diversi. E quando durante i cicli di elaborazione, la RAM e così via erano costosi, non si riteneva valesse lo sforzo di forzare compilatori e computer a essere & Quot; perdonare & Quot; le persone stavano solo cercando di far funzionare le cose .

Nota come l'insensibilità ai casi non è diventata davvero utile fino a quando non sono arrivate cose come Visual Basic insieme - una volta che le aziende hanno iniziato a investire nel concetto secondo cui far programmare le masse era una buona cosa per la loro linea di fondo (ovvero, Microsoft guadagna di più se ci sono più programmi su Windows) le lingue hanno iniziato a essere più amichevoli e più indulgenti.

Altri suggerimenti

Non credo che otterrai una risposta migliore di " perché gli autori di quella lingua hanno pensato che fosse meglio così " ;. Personalmente, penso che abbiano ragione. Non vorrei trovare queste righe ovunque nello stesso file sorgente (e fare riferimento allo stesso oggetto + metodo) ...

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

Non penso che nessuno sarebbe felice di vederlo ...

Una cosa interessante da considerare è che l'inglese è sensibile al maiuscolo / minuscolo. (Sospetto che ciò sia vero per la maggior parte delle lingue naturali, ma potrebbe non essere vero per tutti.)

C'è una grande differenza (dove vivo, comunque, vicino alla città di Reading) tra:

Mi piace leggere.

Allo stesso modo, mentre molte persone fanno capitalizzano in modo errato e di solito puoi capire cosa si intende, ciò non significa che tale scrittura sia considerata corretta . Sono un pignolo quando si tratta di questo tipo di cose, il che non vuol dire che io ottenga tutto bene, ovviamente. Non so se sia parte dell'eredità della distinzione tra maiuscole e minuscole del linguaggio di programmazione, ma sospetto che possa esserlo.

Un netto vantaggio della distinzione tra maiuscole e minuscole per i linguaggi di programmazione è che il testo diventa culturalmente insensibile. È abbastanza grave dover occasionalmente precisare a un compilatore quale codifica di testo viene utilizzata per un file di origine - dover specificare in quale cultura è ancora peggio :(

In realtà è estremamente pratico, sia per lo sviluppatore che per le specifiche della sintassi del linguaggio: la distinzione tra maiuscole e minuscole aggiunge molta espressività alla denominazione degli identificatori.

Dal punto di vista della sintassi del linguaggio, è possibile forzare determinati identificatori a iniziare con lettere minuscole o maiuscole (ad esempio il nome della classe Java). Ciò semplifica l'analisi e quindi aiuta a mantenere pulita la sintassi.

Dal punto di vista degli sviluppatori, ciò consente un gran numero di comode convenzioni di codifica, rendendo il codice più chiaro e più facile da capire.

La mia ipotesi sarebbe che la distinzione tra maiuscole e minuscole allarga lo spazio dei nomi. Un bel trucco come

MyClass myClass;

sarebbe impossibile con il compilatore senza distinzione tra maiuscole e minuscole.

La piegatura delle maiuscole è semplice solo in inglese (e per tutti i caratteri < 128). Il tedesco sz o & Quot; sharp s & Quot; (& # 223;) non ha una variante maiuscola nel set di caratteri ISO 8859-1. Ne ha ricevuto uno solo in Unicode dopo circa un decennio di discussioni (e ora, tutti i caratteri devono essere aggiornati ...). Kanji e Hiragana (alfabeti giapponesi) non conoscono nemmeno le lettere minuscole.

Per evitare questo pasticcio, anche in questa era di Unicode, non è saggio consentire l'identificazione di maiuscole / minuscole e unicode.

Quando l'analisi e la compilazione erano molto costose e richiederebbero tutta la notte, sarebbe stato vantaggioso per il compilatore se non dovesse preoccuparsi del caso.

Una volta emersi identificatori che erano unici solo nel loro caso, è diventato molto difficile tornare indietro. A molti sviluppatori è piaciuto e non sembra esserci un grande desiderio di annullarlo.

ExpertSexChange

Credo che questo sia un concorrente di Stack Overflow dove devi pagare per leggere le risposte. Hmm ... con insensibilità al maiuscolo / minuscolo, il significato del nome del sito è ambiguo.

Questa è una buona ragione per le lingue che fanno distinzione tra maiuscole e minuscole. Meno ambiguità! L'ambiguità con i programmatori è considerata schifosa.

La distinzione tra maiuscole e minuscole aumenta la leggibilità del linguaggio mediante l'uso di convenzioni di denominazione. Non puoi scrivere

Person person = new Person("Bill");

se la tua lingua non fa distinzione tra maiuscole e minuscole, perché il compilatore non sarebbe in grado di distinguere tra il nome della classe e il nome della variabile.

Inoltre, avere Persona, persona, PersoN, PeRsOn e PERSON, tutti token equivalenti mi darebbe mal di testa. :)

Qual è la forma maiuscola di i ? I (U + 0049) o & # 304; (U + 0130)?

Le maiuscole dipendono dalle impostazioni locali.

Molte lingue (non di programmazione) (ad es. europee che usano l'alfabeto romano) fanno distinzione tra maiuscole e minuscole, quindi è naturale per i madrelingua di quelle lingue usare distinzioni maiuscole / minuscole.

L'idea stessa che i linguaggi di programmazione non facciano distinzione tra maiuscole e minuscole è un artefatto storico derivante dalle limitazioni dell'hardware di prima generazione (comprese le macchine di teletipo pre-computer che utilizzavano un carattere a 5 bit codice).

Le persone che sostengono le lingue non vedenti devono essere incapaci di distinguere

IAmNowHere

IAmNowhere

( È uno scherzo! ;-)

Perché sono stupidi come una scatola di rane , proprio per le ragioni fornite per il punto di vista opposto in questo thread (non chiederò nemmeno di cosa si tratta. Legno per gli alberi e tutto il resto).

Quando FOOBAR = FooBar = foobar, puoi scegliere la tua convenzione e altri programmatori possono fare lo stesso indipendentemente dal fatto che condividano o meno le tue preferenze . Nessuna confusione.

Inoltre non possono cavarsela con il colpo di genio che ha una costante, una funzione e una variabile tutte con lo stesso nome nello stesso file, anche se con maiuscole diverse. Ancora una volta, nessuna confusione.

Chiamate il vostro sito Web variabile, chiamano il loro sito Web e quale sistema viene confuso? Nemmeno una cattura facile, durante la scansione.

Per quanto riguarda le ricerche, è davvero molto più elaborato convertire il nome in minuscolo prima di cercarlo? Fare la tua ottimizzazione prematura è una cosa, aspettarsi dallo sviluppatore della tua lingua preferita è un altro livello di mancanza del punto.

... eppure, tutte queste risposte dicendo che la distinzione tra maiuscole e minuscole riduce la confusione. Sigh

C'è anche Common Lisp, che è un linguaggio sensibile al maiuscolo / minuscolo che molte persone credono erroneamente insensibile al maiuscolo / minuscolo. Quando si digita (car x) nel Listener, si trasforma in (CAR X) per l'elaborazione. È possibile definire simboli con nomi in minuscolo, ma devono essere citati con qualcosa come |lower-case-symbol|. Pertanto, digitando (Car X) o <=> o <=> tutto funziona allo stesso modo.

(p per sapere cosa è successo lì.)

La maiuscola di una lettera non è un concetto universale . Java utilizza Unicode, quindi se si desidera Java senza distinzione tra maiuscole e minuscole, il significato del programma potrebbe cambiare a seconda delle impostazioni locali in cui è stato compilato.

La maggior parte delle lingue non ti consente di mettere punti o virgole (o apostrofi o spazi) nel mezzo di valori letterali interi, probabilmente perché dipende anche dalle impostazioni locali.

Da Guida per gli sviluppatori di .NET Framework Convenzioni di capitalizzazione , Case-Sensitivity:

Esistono le linee guida per la capitalizzazione   unicamente per facilitare gli identificatori   leggi e riconosci. L'involucro non può essere   usato come mezzo per evitare il nome   collisioni tra elementi della biblioteca.

Non dare per scontato che tutta la programmazione   le lingue fanno distinzione tra maiuscole e minuscole. Loro sono   non. I nomi non possono differire per caso   da solo.

Come urli se non hai CAPS ?! AHHH!

Devi essere espressivo. Ma in tutta onestà, tra tutte le persone nel mondo, coloro che lavorano con la logica di programmazione sarebbero i primi a insistere sul fatto che le differenze sono in realtà differenze.

La distinzione tra maiuscole e minuscole non aiuta davvero la coerenza dei casi.

Foo.Bar  
foo.Bar  
fOO.bAR

In un linguaggio insensibile alle maiuscole che può essere facilmente risolto automaticamente dall'editor. In un linguaggio sensibile al maiuscolo, risolverlo è più difficile in quanto potrebbe essere legale. L'editor deve prima verificare se esistono foo.Bar e fOO.bAR e deve anche indovinare che hai digitato nel caso sbagliato invece di dimenticare di dichiarare la variabile (poiché Foo è diverso da fOO).

Molte persone qui hanno detto che sarebbe male per diverse forme di capitalizzazione fare riferimento alla stessa cosa, ad esempio:

person
perSoN
PERSON

Ciò che sarebbe veramente brutto è se tutti facessero riferimento a diversi oggetti nel codice. Se hai variabili person, perSoN e PERSON tutte riferite a cose diverse, hai un problema.

Ogni esempio che ho visto a sostegno della distinzione tra maiuscole e minuscole si basa sul desiderio di scrivere codice negativo e non descrittivo. per esempio. il " data " vs. " myDate " argomento: sono entrambi ugualmente non descrittivi e cattive pratiche. La buona pratica è nominarla come è in realtà: data di nascita, data di assunzione, data di fatturazione, qualunque cosa. E chi nella loro mente giusta vorrebbe scrivere codice come:

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

Sorprendentemente questo è un caso perfettamente valido in codice VB.Net sensibile. Il pensiero che la distinzione tra maiuscole e minuscole ti permetta di disobbedire ancora più palesemente alle buone pratiche di programmazione è un argomento contro di essa, non per questo.

Perché molte persone trovano employeeSocailSecurityNumber altrettanto leggibile di employee_social_security_number ed è più breve.

Penso che avere un linguaggio con distinzione tra maiuscole e minuscole INCORAGGIA le persone a scrivere codice scadente.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

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

Duh. Non potresti pensare a un nome di variabile migliore di & Quot; ShoeSize & Quot; per i diversi scopi? Ci sono un miliardo di parole diverse che potresti usare, ma scegli di continuare a usare ShoeSize invece?

E potresti anche (stupidamente) usare solo lettere singole (" a " e " b " e " c " ;) per tutte le classi, variabili, funzioni e metodi.

Ma PERCHÉ vorresti farlo?

Usa nomi che hanno un senso , non:

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

C'è un'altra ragione per cui le lingue fanno distinzione tra maiuscole e minuscole. Gli ID possono essere memorizzati in una tabella hash e le tabelle hash dipendono dalle funzioni di hashing che daranno hash diversi per casi diversi. E potrebbe non essere conveniente convertire tutti gli ID in tutti i valori superiori o inferiori prima di eseguirli tramite la funzione hash. Mi sono imbattuto in questo problema mentre scrivevo il mio compilatore. È stato molto più semplice (più pigro) dichiarare la mia lingua tra maiuscole e minuscole.

Ho letto l'intera discussione. Devo credere che quelli che dichiarano di aver trovato valore nel caso la sensibilità non abbia mai programmato in un vero linguaggio di alto livello (che per definizione non fa distinzione tra maiuscole e minuscole). K & Amp; R ammette che C è di livello medio. Dopo aver programmato in Pascal, Delphi, Lazarus, ADA, ecc., Si apprende che il codice altamente leggibile è semplice da scrivere e da eseguire rapidamente senza ossessionare costrutti concreti. Dopo tutto, la leggibilità è la prima e l'ultima parola sull'argomento. Il codice è scritto per l'umano, non per il computer. Nessun problema con il debug con codice insensibile al maiuscolo / minuscolo. Quando si passa a una lingua di livello medio, si scopre che NON ci sono vantaggi per la distinzione tra maiuscole e minuscole. Vi è tuttavia un numero considerevole di ore trascorse nel debug della sensibilità del caso che ha causato problemi. Soprattutto quando si mettono insieme moduli di programmatori diversi. Sembra anche che un gran numero di intervistati non capisca cosa si intende per insensibilità al caso. Sono interessati solo i caratteri dalla a alla z. Questi sono un sottoinsieme sequenziale di caratteri ASCII. Tre o quattro byte di codice macchina rendono il compilatore indifferente al caso in questo intervallo di caratteri. Non altera la barra inferiore, i numeri o qualsiasi altra cosa. I punti su altre lingue e set di caratteri semplicemente non si applicano a questa discussione. Il compilatore o l'interruttore sarebbe codificato per convertire temporaneamente o non convertire il carattere per l'analisi in fase di compilazione in base all'essere ASCII o meno.

Sono scioccato dalle nuove lingue come Python che sono venute fuori ripetendo l'errore commesso da K & amp; R. Sì, hanno salvato una mezza dozzina di byte in un ambiente in cui la RAM totale per il compilatore, il codice sorgente e il codice oggetto era 1000 byte. Quello era allora. Ora la memoria non è un problema. Ora, per nessuna ragione ragionevole, anche le parole di riserva in Python fanno distinzione tra maiuscole e minuscole! Non credo che dovrò usare & Quot; Per & Quot; di " Stampa " come nome variabile o funzione. Ma questa possibilità è stata preservata dal dispendioso tempo trascorso a contendere con l'interrutore per il caso esatto di ciascun identificatore. Penso che sia un cattivo affare.

La cosa più vicina che ho letto fino ad oggi a sostegno della distinzione tra maiuscole e minuscole sono i commenti su Hashing. Ma questi rari eventi di codifica che possono essere gestiti con attenzione ai dettagli non sembrano valere la pena inutile che un programmatore deve usare per scrivere codice sensibile al maiuscolo / minuscolo. Due punti di vista del problema. Uno incoraggia una cattiva codifica, imposta trappole nel codice e richiede un'attenzione extra per deviare dai concetti più grandi. L'altro non ha il rovescio della medaglia, ha funzionato perfettamente in lingue di alto livello e consente flessibilità se non fa male. Mi sembra che l'ennesimo caso di VHS vinca il BETA. Vale solo i miei due centesimi qui.

L'apprendimento è sempre più semplice con l'esempio, quindi eccolo qui:

C # (case sensitive ma utilizzabile da VB.NET che non fa distinzione tra maiuscole e minuscole):

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 usano uno stile simile a C # ma metodi / funzioni / eventi sono dichiarati come variabili doSomething, onEvent.

ObjectPascal (Delphi e Lazarus / FPC non fanno distinzione tra maiuscole e minuscole, come 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

L'uso di OneCase e dei prefissi per ogni tipo ha senso in tutte le lingue. Anche le lingue che sono iniziate senza prefissi hanno costrutti più recenti come le interfacce che non si basano sul caso ma usano invece un prefisso.

Quindi non è davvero importante se una lingua fa distinzione tra maiuscole e minuscole. Sono stati aggiunti concetti più recenti ai linguaggi sensibili al maiuscolo che erano troppo confusi per essere espressi dal solo caso e che richiedevano l'uso di un prefisso.

Poiché le lingue con distinzione tra maiuscole e minuscole hanno iniziato a utilizzare i prefissi, è ragionevole smettere di usare maiuscole e minuscole con lo stesso nome identificativo someIdentifier SomeIdentifier SOME_IDENTIFIER, ISomeIdentifier e utilizzare i prefissi laddove ha senso.

Considera questo problema: Hai un membro della classe chiamato qualcosa, un parametro metodo / funzione chiamato qualcosa e una variabile locale chiamata qualcosa, quale convenzione del caso potrebbe essere utilizzata per distinguere facilmente tra questi? Non è più semplice usare il ConsistentCaseStyle più ovunque e aggiungere un prefisso?

I fan delle lingue insensibili alle maiuscole si preoccupano della qualità del codice, vogliono solo uno stile. A volte accettano il fatto che una libreria sia scritta male e usano uno stile rigoroso mentre la libreria potrebbe non avere uno stile o un codice scadente.

Entrambi i linguaggi sensibili al maiuscolo / minuscolo richiedono una disciplina rigorosa, ha più senso avere un solo stile ovunque. Sarebbe meglio se avessimo un linguaggio che utilizzava solo StrictCase, uno stile ovunque e prefissi.

C'è molto codice C scadente, la distinzione tra maiuscole e minuscole non lo rende leggibile e non puoi farci nulla. In un linguaggio senza distinzione tra maiuscole e minuscole è possibile applicare un buon stile nel codice senza riscrivere la libreria. In un linguaggio StrictCase che non esiste ancora, tutto il codice avrebbe una qualità decente :)

Sembra che la maggior parte delle persone sia d'accordo sul fatto che la distinzione tra maiuscole e minuscole sia importante e sono d'accordo.

Tuttavia, può essere fastidioso digitare qualcosa nel caso corretto, quindi penso che l'IDE dovrebbe permetterti di digitare il caso sbagliato, ma se si preme il collegamento di completamento automatico dovrebbe fare una corrispondenza insensibile al caso. Questo ci dà il meglio di entrambi i mondi.

In base agli standard di codifica tipici, Person sarebbe una classe, person un nome variabile e PERSON una costante. È spesso utile usare la stessa parola con lettere maiuscole diverse per indicare qualcosa di correlato ma leggermente diverso.

Quindi, se nella tua azienda avessi tre membri dello staff tutti chiamati Robert, ti riferiresti a loro come faresti Robert, Robert e ROBERT? E fare affidamento sulle persone per sapere esattamente quale intendevi?

Fornisci loro indirizzi e-mail come Robert@widgets.com, robert@widgets.com e ROBERT@widgets.com se il tuo sistema di posta elettronica fa distinzione tra maiuscole e minuscole?

Il potenziale per una violazione non autorizzata dei dati personali sarebbe enorme. Per non parlare se hai inviato la password di root del database al dipendente scontento che sta per essere licenziato.

Meglio chiamarli Bob, Robbie e Robert. Meglio ancora chiamarli Robert A, Robert B e Robert C se i loro cognomi fossero ad es. Arthur, Banks e Clarke

Davvero - perché mai una convenzione di denominazione che invita errori o confusione, che si basa sul fatto che le persone sono molto vigili? Sei così a corto di parole nel tuo volcabolario?

E per quanto riguarda la persona che menziona il trucco apparentemente utile " MyClass myClass " - perché perché perché? Rendi deliberatamente difficile capire a colpo d'occhio se un metodo utilizzato è un metodo di classe o un metodo di istanza.

Inoltre hai perso la possibilità di dire alla persona successiva che legge di più il tuo codice sulla particolare istanza della classe.

Ad esempio.

Cliente Precedente Cliente

Cliente NewCustomer

Cliente CorporateCustomer

Il nome della tua istanza deve idealmente dire al tuo collega più della semplice classe su cui si basa!

Se la separazione delle parole non è importante, allora perché mettiamo spazi tra le parole? Pertanto penso che le sottolineature tra le parole in un nome aumentino la leggibilità. Anche le lettere minuscole con maiuscole e minuscole dei caratteri appropriati sono più facili da leggere. Infine, è sicuramente molto più semplice se tutte le parole possono essere trasmesse dal passaparola - & Quot; Corporate Underscore Customer & Quot; anziché " Maiuscole C Minuscole o r p o r ae Underscore Maiuscole C minuscole è possibile utilizzare " ;! - il primo può essere pronunciato "nella propria testa", il secondo no. - Mi chiedo come le persone che sono felici della sensibilità al maiuscolo gestiscano questi nomi sensibili al cervello - Faccio davvero fatica. Quindi ritengo che la distinzione tra maiuscole e minuscole non sia affatto utile, a mio avviso un passo indietro rispetto a COBOL.

Perché le persone pensano troppo alle cose.

L'insensibilità al maiuscolo / minuscolo funziona meglio quando preserva anche il maiuscolo / minuscolo e combinato con una separazione tra spazi dei nomi di tipo e variabili. Ciò significa che:

Se dichiari una classe come 'TextureImage' e poi cerchi di usarla come 'textureImage', l'IDE può correggerti automaticamente. Questo ti dà il vantaggio di non dover mai premere il tasto Maiusc a meno che non dichiari un identificatore o usi un trattino basso.
Proprio come in Java e in molte altre lingue; è perfettamente valido digitare " MyClass myClass " ;. L'IDE e il compilatore non dovrebbero avere problemi a distinguere tra l'uso di un tipo e l'uso di una variabile.

Inoltre, l'insensibilità alle maiuscole garantisce che 'o' e 'O' non faranno mai riferimento a oggetti diversi. Argomenti comuni includono:

quot &; & sOmEoNe wIlL tYpE cOdE lIkE tHiS Quot ;; = Gt &; e che a qualcuno non sarà mai permesso di unirsi a un team di programmazione, quindi questo è un argomento di paglia. anche se sono riusciti a farlo, l'insensibilità ai casi è più la soluzione che il problema, perché significa che non devi ricordare quale pazza combinazione maiuscola / minuscola usano.
" non è possibile internazionalizzare facilmente l'insensibilità ai casi! " ;; = Gt &; oltre il 95% dei linguaggi di programmazione è scritto in inglese per un'ottima ragione. non ci sono codifiche di caratteri concorrenti e la stragrande maggioranza delle tastiere sulla terra sono basate in inglese (in tutto o in parte). supportare gli identificatori unicode è forse l'idea più stupida che qualcuno abbia mai avuto nel 21 ° secolo; poiché una buona parte dei caratteri unicode sono resi invisibili a frikkin, la lettura del codice è abbastanza difficile senza dover usare google translate, e scrivere il codice è abbastanza difficile senza dover copiare e incollare identificatori o usare una mappa di caratteri.
" ma le lingue con distinzione tra maiuscole e minuscole hanno più identificatori! " ;; = Gt &; no, hanno identificatori grammaticalmente sovraccarichi, il che è sostanzialmente peggio.

Non uso linguaggi senza distinzione tra maiuscole e minuscole, ma i vantaggi sono palesemente ovvi se pensi seriamente a questo genere di cose.

Una risposta ragionevole potrebbe essere che i progettisti del linguaggio lo pensassero renderebbe la lingua più facile da capire pensando al futuro :)

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow