Non vedo alcun utilizzo per la distinzione tra maiuscole e minuscole in un linguaggio di programmazione, a parte l'offuscamento del codice.
Perché implementarlo in un linguaggio di programmazione?
Aggiornamento:
Sembra qualcuno che conosci ha fatto una dichiarazione su questo .
Mentre la piegatura del caso è abbastanza banale in inglese, è molto meno in alcune altre lingue.
Se un programmatore tedesco usa ß in un nome di variabile, quale sarà l'equivalente maiuscolo? Solo FYI, "ß" è sempre e solo usato in minuscolo. OTOH, "ss" è equivalente - considereresti un compilatore obbligato ad abbinarli? Quando si entra in Unicode, si ottengono problemi ancora più interessanti, come i caratteri con segni diacritici precompilati rispetto a separare i segni diacritici. Quindi si arriva ad alcuni script arabi, con tre diverse forme di molte lettere, piuttosto che solo due.
Nelle epoche oscure la maggior parte dei linguaggi di programmazione era insensibile alle maiuscole e minuscole quasi per necessità. Ad esempio, Pascal è stato avviato sui mainframe di Control Data, che utilizzavano solo sei bit per carattere (64 codici, totale). La maggior parte di queste macchine utilizzava il set di caratteri "CDC Scientific", che conteneva solo caratteri maiuscoli. È possibile passare ad altri set di caratteri, ma la maggior parte ha maiuscolo o minuscolo, ma non entrambi, ma ha utilizzato gli stessi codici per entrambi. Lo stesso valeva per gli antichi codici Baudot e per lo standard considerato nei primi giorni di COBOL, FORTRAN, BASIC, ecc. Quando l'hardware più capace era ampiamente disponibile, il loro essere insensibili al caso era così profondamente radicato che cambiare era impossibile .
Nel corso del tempo, la vera difficoltà dell'insensibilità al caso è diventata più evidente ei progettisti di linguaggio hanno deciso per lo più ("realizzato" sarebbe probabilmente un termine più accurato) quando / se le persone vogliono davvero insensibilità alle maiuscole e minuscole, che è meglio gestirle da strumenti ausiliari rispetto al linguaggio stesso.
Almeno IMO, il compilatore dovrebbe prendere input esattamente come presentato, non decidere che "hai scritto questo, ma assumerò che tu intenda davvero qualcos'altro". Se vuoi che le traduzioni accadano, è meglio farle separatamente, con strumenti costruiti per gestirle bene.
Perché qualcuno VOGLIA di insensibilità al caso? In quale scenario è utile poter fare riferimento a una singola variabile come VARIABLE in un posto, Variable in un altro e variable in un terzo? L'insensibilità al caso è esasperante. Preferisco di gran lunga un errore del compilatore quando digito accidentalmente VAriable anziché Variable piuttosto che lasciare che case-refusi del genere scorrano nel mio codice.
In conclusione, molti linguaggi di programmazione hanno la distinzione tra maiuscole e minuscole non solo per motivi storici / inerziali, ma perché l'insensibilità alle maiuscole / minuscole è una cattiva idea.
In Java la distinzione tra maiuscole e minuscole non è utilizzata per fornire più opzioni nel codice, ma piuttosto per un significato semantico molto chiaro e coerente. ClassesLookLikeThis. objectsLookLikeThis. methodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NON offre una maggiore libertà: ti consente di raggruppare alcune informazioni in modo conciso in un linguaggio altrimenti eccessivamente prolisso.
Penso che in linguaggi esplicitamente tipizzati staticamente con il compilatore mucho e il supporto IDE, la distinzione tra maiuscole e minuscole è un ottimo modo per comunicare informazioni (ad esempio, Java). Con linguaggi come Ruby, l'insensibilità alle maiuscole / minuscole causerebbe probabilmente anche MAGGIORI risultati inaspettati, anche se sarei aperto a provare Ruby senza distinzione tra maiuscole e minuscole.
Penso che la case sensitive con un sistema rigoroso non offuschi il codice ma in realtà lo renda più chiaro. Considera un possibile codice Java:
joe blah = new hUf();
questo è abbastanza chiaro, ma che dire:
hUf.WTF();
In Java così com'è, sapresti automaticamente di cosa si tratta. In Java senza distinzione tra maiuscole e minuscole, è ambiguo, quindi avresti bisogno di ricorrere a qualche altro meccanismo per differenziare le classi dalle istanze dai pacchetti ai metodi. E QUESTO meccanismo potrebbe probabilmente farti vomitare con quanto è brutto :)
Non penso che sia stato "implementato" tanto quanto "permesso". La distinzione tra maiuscole e minuscole è lo stato predefinito dei confronti tra stringhe; ci vuole del lavoro extra per l'ingegnere del compilatore per rendere insensibile il linguaggio, poiché è necessario aggiungere un codice extra per eseguire confronti senza distinzione tra maiuscole e minuscole e conservare i nomi dei token originali per la corretta segnalazione di errori e avvisi.
Questo è quasi certamente il motivo per cui è finito in C; volevano creare un linguaggio semplice che fosse facile da implementare per un compilatore, a scapito dell'usabilità. Per quanto riguarda il motivo per cui è nelle langauges moderne? Perché è in C, ovviamente, quindi deve essere il modo giusto per farlo! < / sarcasm mode >
Se non altro, semplifica l'analisi e consente più combinazioni per nomi di variabili / classi.
Con l'analisi senza distinzione tra maiuscole e minuscole, ti verrebbe limitato a dover utilizzare identificatori univoci, poiché "myClass" e "MyClass" sarebbero la stessa cosa. In alternativa, dovresti aggiungere livelli di complessità al parser per assicurarti di poter determinare quale identificatore viene utilizzato in base al contesto.
Considera un caso come questo:
XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");
Supponiamo che la classe XmlWriter abbia anche un metodo statico chiamato "Write". La stai chiamando sull'istanza o sulla classe, se qui non è applicata la distinzione tra maiuscole e minuscole?
Mi piace la distinzione tra maiuscole e minuscole se non altro perché rende il codice più auto-documentante:
this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename
Di solito programma in Python, ma tornando ai miei C # giorni, ho trovato molto comodo dare un nome alle istanze di classe uguali a quelle della classe, ma inferiore (o cammello) (come altri hanno detto):
Thing thing = new Thing();
L'uso di linguaggi insensibili alle maiuscole richiede qualche altra convenzione per questo, ad esempio una sorta di sigillo come:
Thing oThing = new Thing()
Thing instanceOfThing = new Thing()
Che è una "brutta cosa".
Trovo anche comodo a grep (caso-sensibile) per trovare il riferimento a una classe rispetto agli usi di una variabile. Con un linguaggio insensibile alle maiuscole, questo sarebbe meno facile. Lo stesso per la ricerca e l'amp; sostituzione.
Infine, come programmatore, quando vedo parole con diversi casi, mi viene in mente che sono cose diverse ... Raramente ho bug in cui i casi variabili sono stati sbagliati, anche in linguaggi dinamici e programmati in cui un compilatore hai aiutato.
Le persone prestano attenzione alla forma delle parole prima ancora di leggerle. La distinzione tra maiuscole e minuscole mantiene la forma di un simbolo coerente in tutto il codice. Sono d'accordo anche con quelli di cui sopra che affermano che convenzioni diverse denotano diversi tipi di simboli. La maiuscole e l'insensibilità possono essere entrambe abusate. I programmatori cattivi genereranno sempre codice errato ... troveranno un modo.
Prendi la lingua come esempio. Perché iniziamo frasi e nominiamo le cose con lettere maiuscole ... È anche a causa di unix?
Penso che per i linguaggi tipizzati staticamente come C # e Java, in realtà non aggiunga alcun valore. Poiché nella maggior parte dei casi, hai un IDE che correggerà automaticamente le disallineamenti dei casi per te, quindi alla fine della giornata, se digito "VAriable" per errore, il mio IDE la correggerà automaticamente " Variabile "per me. Aggiungi a questo le convenzioni di stile MyClass myClass; e puoi notare che la sensibilità alle maiuscole / minuscole non è necessariamente una cosa negativa.
Per linguaggi tipizzati dinamicamente, potrebbe esserci più di un argomento, dal momento che è più difficile per un IDE indovinare una correzione automatica, ma nel caso di lingue con dattilografia dinamica, hai già molto di più di cui preoccuparti ( in termini di errori di battitura) che l'uso di una convenzione di custodia coerente non aggiungerà altro peso.
Quindi sì, mentre non esiste una vera ragione per cui le lingue non non siano case-insensitive, non c'è nemmeno una vera ragione per cui dovrebbe essere o.
L'articolo di Scott Hanselman su "SignOn" vs "Signon" riguardava il confronto di stringhe e nulla a che fare con i linguaggi di programmazione. Sono d'accordo sul fatto che le stringhe che gli utenti digitano dovrebbero sempre confrontare caso-insensibile, ma penso che sia un gioco diverso per gli identificatori in un linguaggio di programmazione.
Quando una lingua fa distinzione tra maiuscole e minuscole, ne approfitto per riprodurre l'uso di casi convenzionali in matematica e scienze. Ecco un elenco (in nessun caso esaustivo) di alcune convenzioni sui casi:
f di solito rappresenta una funzione di densità di probabilità (pdf), mentre la maiuscola F rappresenta la funzione di distribuzione cumulativa corrispondente (cdf).
X , e le lettere minuscole corrispondenti indicano le loro realizzazioni x , come in $ Pr [X = x] \ leq 0.05 $.
Ho appena immaginato che fosse a causa di Unix e C - ma è una specie di pollo e il problema dell'uovo che solo i geezer possono rispondere correttamente.
Uso la logica che i polli di "Il coniglietto pasquale sta arrivando in città" usavano quando chiedevano se venivano prima delle uova. Poiché c'erano polli nell'arca di Noè, i polli arrivarono per primi. Quindi, dato che GCC gira su Unix, Unix è venuto prima, quindi perché Unix si prende così tanto per il caso, C e tutte le sue varianti e discendenti, qualsiasi cosa che imponga parentesi graffe, cura il caso.
Probabilmente esiste anche un collegamento tra parentesi graffe e distinzione tra maiuscole e minuscole.
Oltre alle eccellenti risposte fornite finora, vorrei sottolineare che la distinzione tra maiuscole e minuscole offre anche ulteriori "namespace". Per esempio Perl ha alcuni blocchi speciali come BEGIN e END che vengono eseguiti in tempi diversi rispetto al codice normale (BEGIN in fase di compilazione, END dopo che il normale programma è terminato), e avere quelli come maiuscole li fa risaltare, e significa che le varianti minuscole non sono parole riservate.
Si può andare ancora oltre e riservare nomi maiuscoli per l'uso futuro da parte della lingua, e non fare alcun danno ai normali programmatori, che di solito NON HANNO LETTO NEL LORO CODICE.
"Case sensitive" è sempre meglio per le persone tecniche per ridurre l'ambiguità. Prendi il nome del file come esempio. Trattare con il nome file di Windows è più problematico del nome file Unix poiché il nome file in Windows non fa distinzione tra maiuscole e minuscole mentre il nome file in Unix fa distinzione tra maiuscole e minuscole.
Torna alla programmazione. Per il nome della classe, il nome del metodo, il nome della variabile, la maggior parte della lingua non impone la regola dello stile di denominazione. A volte, per semplificare la "riflessione", possiamo semplicemente usare il nome "Case sensitive" per associarlo ad altre origini dati senza conversione o gestire il problema con lo stesso nome ma in casi diversi.
Sono sorpreso da questo sfogo. Ora che nessuno vuole che tu usi un trattino basso o un m_ nel nome di un campo in C #, ho appena usato il caso cammello e se il nome del campo è lo stesso di un nome di proprietà pubblica, solo il nome di proprietà pubblica è il caso Pascal e il campo di supporto è il caso dei cammelli, immagino, "così sia" - questo è ciò che la comunità di programmazione in generale sembra volere. Fino ad ora non ha causato problemi.
Specialmente alcuni programmatori vengono dai primi giorni del BASIC, dove un nome di variabile può essere lungo solo 2 caratteri.
E così, quando può essere un numero qualsiasi di personaggi, diventano molto felici. E insieme alla distinzione tra maiuscole e minuscole - perché non vogliono nemmeno preoccuparsi che SomeName sia accidentalmente uguale a SOMENAME e causi un bug a causa di cose come questa.
Leggi altre domande sui tag programming-languages syntax