Perché in alcuni linguaggi di programmazione esiste ancora la distinzione tra maiuscole e minuscole?

Non vedo alcun uso per la distinzione tra maiuscole e minuscole in un linguaggio di programmazione, a parte il codice offuscato.

Perché implementarlo in un linguaggio di programmazione?

Aggiornare:

Sembra che qualcuno che conosci abbia fatto una dichiarazione al riguardo .

Mentre la piegatura del case è abbastanza banale in inglese, lo è molto meno in alcune altre lingue. Se un programmatore tedesco usa ßun nome di variabile, cosa considererai l'equivalente in maiuscolo? Cordiali saluti, "ß" è sempre e solo usato in minuscolo. OTOH, "ss" è equivalente - considereresti un compilatore obbligato ad abbinarli? Quando entri in Unicode, ottieni problemi ancora più interessanti, come i personaggi con segni diacritici precomposti rispetto ai diacritici combinati separati. Quindi si arriva ad alcuni script arabi, con tre forme separate di molte lettere, anziché solo due.

Nei secoli bui la maggior parte dei linguaggi di programmazione non distingue tra maiuscole e minuscole per necessità. Ad esempio, Pascal è partito dai mainframe Control Data, che utilizzavano solo sei bit per carattere (64 codici, totale). La maggior parte di tali macchine utilizzava il set di caratteri "CDC Scientific", che conteneva solo caratteri maiuscoli. Potresti passare ad altri set di caratteri, ma la maggior parte aveva caratteri maiuscoli o minuscoli, ma non entrambi - ma utilizzava gli stessi codici per entrambi. Lo stesso valeva per gli antichi codici Baudot e simili considerati agli inizi di COBOL, FORTRAN, BASIC, ecc. Quando l'hardware più capace era ampiamente disponibile, il loro insensibilità al case era così profondamente radicato che cambiarlo era impossibile .

Nel corso del tempo, la reale difficoltà di insensibilità al maiuscolo / minuscolo è diventata più evidente, e i progettisti del linguaggio hanno deciso per lo più ("realizzato" sarebbe probabilmente un termine più accurato) che quando / se le persone vogliono davvero insensibilità al caso, è meglio gestita da strumenti ausiliari che nella lingua stessa.

Almeno IMO, il compilatore dovrebbe prendere l'input esattamente come presentato, non decidere che "hai scritto questo, ma suppongo che tu abbia davvero significato qualcos'altro". Se vuoi che le traduzioni avvengano, è meglio farle separatamente, con strumenti creati per gestirlo bene.

Perché qualcuno VOGLIA l'insensibilità al caso? In quale scenario è utile poter fare riferimento a una singola variabile come VARIABLEin un posto, Variablein un altro e variablein un terzo? L'insensibilità al caso è esasperante. Preferirei di gran lunga ottenere un errore del compilatore quando scrivo per sbaglio VAriableinvece di Variablelasciare che errori di battitura come quello scivolino nel mio codice.

In conclusione, molti linguaggi di programmazione hanno la distinzione tra maiuscole e minuscole non solo per ragioni storiche / inerziali, ma perché l'insensibilità alle maiuscole è una cattiva idea.

In Java la sensibilità del case NON viene 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à: consente di racchiudere alcune informazioni in modo conciso in un linguaggio altrimenti eccessivamente prolisso.

Penso che in linguaggi esplicitamente digitati staticamente con compilatore mucho e supporto IDE, la distinzione tra maiuscole e minuscole sia un ottimo modo per comunicare informazioni (ad es. Java). Con linguaggi come Ruby, l'insensibilità ai casi probabilmente causerebbe ANCORA risultati inaspettati, anche se sarei aperto a provare Ruby senza distinzione tra maiuscole e minuscole.

Penso che la distinzione tra maiuscole e minuscole con un sistema rigoroso non offuschi il codice ma lo renda effettivamente più chiaro. Considera il possibile codice Java:

      joe blah = new hUf();

è abbastanza chiaro, ma per quanto riguarda:

      hUf.WTF();

In Java così com'è, sapresti automaticamente di cosa si tratta. In Java senza distinzione tra maiuscole e minuscole, è ambiguo, quindi dovresti ricorrere a qualche altro meccanismo per differenziare le classi dalle istanze dai pacchetti dai metodi. E QUESTO meccanismo probabilmente ti farebbe vomitare con quanto è brutto :)

Non penso che sia stato "implementato" tanto quanto "permesso". La distinzione tra maiuscole e minuscole è lo stato predefinito dei confronti di stringhe; è necessario un lavoro extra per l'ingegnere del compilatore per rendere insensibile il maiuscolo / minuscolo del linguaggio, poiché è necessario aggiungere un codice aggiuntivo per eseguire confronti senza distinzione tra maiuscole e minuscole e conservare i nomi dei token originali per errori e segnalazioni di avvisi corretti.

Questo è quasi certamente il motivo per cui è finito in C; volevano creare un linguaggio semplice per il quale era facile implementare un compilatore, a spese dell'usabilità. Per quanto riguarda il motivo per cui è in lingue moderne? Perché è in C, ovviamente, quindi deve essere il modo giusto per farlo! </ modalità sarcasmo>

Se non altro, semplifica l'analisi e consente più combinazioni per i nomi di variabili / classi.

Con l'analisi senza distinzione tra maiuscole e minuscole, ti saresti limitato a dover utilizzare identificatori univoci, poiché "myClass" e "MyClass" sarebbero la stessa cosa. In alternativa, dovresti aggiungere livelli di complessità al tuo parser per assicurarti di poter determinare quale identificatore viene utilizzato in base al contesto.

Prendi in considerazione un caso come questo:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Supponiamo che la classe XmlWriter abbia anche un metodo statico chiamato "Scrivi". Lo stai chiamando sull'istanza o sulla classe, se qui non viene applicata la distinzione tra maiuscole e minuscole?

Mi piace la distinzione tra maiuscole e minuscole se non altro per rendere il codice più autocompattante:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

In genere programma in Python, ma nei miei giorni in C #, ho trovato molto conveniente nominare le istanze di classe come la classe, ma maiuscole (o cammello) (come hanno detto altri):

Thing thing = new Thing();

L'uso di linguaggi senza distinzione tra maiuscole e minuscole richiede qualche altra convenzione per questo, cioè una sorta di sigillo come:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Che è una "cosa negativa".

Trovo anche conveniente grep (distinzione tra maiuscole e minuscole) per trovare un riferimento a una classe rispetto agli usi di una variabile. Con un linguaggio senza distinzione tra maiuscole e minuscole, questo sarebbe meno facile. Lo stesso vale per la ricerca e la sostituzione.

Infine, come programmatore, quando vedo parole con casi diversi, mi viene in mente che sono cose diverse ... Raramente ho dei bug in cui i casi variabili erano sbagliati, anche in linguaggi dinamici e con script in cui un compilatore avrebbe aiutato.

Le persone prestano attenzione alla forma delle parole prima di leggerle effettivamente. La distinzione tra maiuscole e minuscole mantiene la forma di un simbolo coerente nel codice. Concordo anche con quelli sopra che affermano che convenzioni diverse denotano diversi tipi di simboli. La sensibilità al caso e l'insensibilità possono essere entrambe abusate. I programmatori errati genereranno sempre un codice errato ... troveranno un modo.

Prendi la lingua come esempio. Perché iniziamo frasi e nominiamo le cose con le maiuscole ... È anche a causa di Unix?

Penso che per linguaggi tipicamente statici come C # e Java, in realtà non aggiunge alcun valore. Perché nella maggior parte dei casi, hai un IDE che correggerà automaticamente i disallineamenti del caso per te, quindi alla fine della giornata, se scrivo "VAriable" per errore, il mio IDE lo correggerà automaticamente in " Variabile "per me. Aggiungete a ciò le MyClass myClass;convenzioni di stile e vedrete che la distinzione tra maiuscole e minuscole non è necessariamente una cosa negativa.

Per i linguaggi tipizzati dinamicamente, potrebbe esserci più di un argomento, poiché è più difficile per un IDE indovinare una correzione automatica, ma nel caso dei linguaggi tipizzati dinamicamente, hai già molto di più di cui preoccuparti (in termini di errori di battitura) che l'uso di una convenzione di involucro coerente non aggiungerà ulteriori oneri.

Quindi sì, anche se non esiste una vera ragione per cui le lingue non possano fare distinzione tra maiuscole e minuscole, non c'è nemmeno una vera ragione per cui dovrebbero esserlo.

Quell'articolo di Scott Hanselman su "SignOn" vs "Signon" parlava di confronti tra stringhe e non aveva nulla a che fare con i linguaggi di programmazione. Concordo sul fatto che le stringhe digitate dagli utenti debbano sempre comparare in modo insensibile alle maiuscole e minuscole, ma penso che sia un gioco di ruolo diverso dagli identificatori in un linguaggio di programmazione.

Quando una lingua fa distinzione tra maiuscole e minuscole, ne approfitto per riprodurre l'uso del caso convenzionale in matematica e scienze. Ecco un elenco (non esaustivo) di alcune convenzioni di casi:

• Nella teoria delle probabilità, le flettere minuscole di solito rappresentano una funzione di densità di probabilità (pdf), mentre Fle lettere maiuscole rappresentano la corrispondente funzione di distribuzione cumulativa (cdf).
• Anche nella teoria della probabilità, le lettere maiuscole indicano variabili casuali Xe le lettere minuscole corrispondenti indicano le loro realizzazioni x, come in $ Pr [X = x] \ leq 0,05 $.
• Nell'algebra lineare, le lettere maiuscole sono generalmente utilizzate per fare riferimento a matrici mentre le lettere minuscole sono generalmente utilizzate per fare riferimento a numeri, ad esempio $ A = [a_ {ij}] $.
• I simboli delle unità sono scritti in lettere minuscole (ad es. M per metro) ad eccezione del litro (L) e delle unità derivate dal nome di una persona (W per Watt, Pa per Pascal, N per Newton e così via).
• I simboli di prefissi che significano un milione o più sono in maiuscolo (M per mega (milioni)), e quelli meno di un milione sono minuscoli (m per milli (millesimi)).

Ho solo pensato che fosse a causa di Unix e C, ma è un po 'un problema con un pollo e un uovo a cui solo i geezer possono rispondere correttamente.

Uso la logica usata dai polli in "Il coniglietto pasquale sta arrivando in città" quando mi è stato chiesto se venivano prima delle uova. Poiché sull'Arca di Noè c'erano polli, le galline vennero per prime. Pertanto, poiché GCC funziona su Unix, Unix è arrivato per primo, quindi perché Unix si preoccupa così tanto del caso, C e tutte le sue varianti e discendenti, sì, tutto ciò che impone parentesi graffe, si prende cura del caso.

Probabilmente esiste anche un legame tra parentesi graffe e sensibilità del case.

Oltre alle eccellenti risposte fornite finora, vorrei sottolineare che la distinzione tra maiuscole e minuscole offre anche "spazi dei nomi" aggiuntivi. Ad esempio, Perl ha alcuni blocchi speciali come BEGINe ENDche vengono eseguiti in tempi diversi rispetto al codice normale (INIZIO in fase di compilazione, FINE dopo che il programma normale è terminato) e avere quelli come maiuscole li fa risaltare, e significa che il minuscolo le varianti non sono parole riservate.

Si può andare ancora oltre e riservare nomi maiuscoli per un uso futuro da parte della lingua, e non arrecare alcun danno ai normali programmatori, che di solito NON VINCONO NEL LORO CODICE.

"Case sensitive" è sempre meglio per le persone tecniche per ridurre l'ambiguità. Prendi il nome del file come esempio. Gestire il nome file di Windows è più problematico del nome file Unix perché 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 nome classe, nome metodo, nome variabile, la maggior parte della lingua non applica la regola di stile di denominazione. A volte, per semplicità, per "riflettere", possiamo semplicemente usare il nome "Case sensitive" per associare 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 carattere di sottolineatura o un m_nome di campo in C #, ho appena usato il caso cammello e se il nome del campo è uguale al nome di una proprietà pubblica, solo che il nome della proprietà pubblica è il caso Pascal e il campo di fondo è il caso dei cammelli, immagino, "così sia" - questo è ciò che la comunità di programmatori sembra volere. Finora non ha causato alcun problema.

Soprattutto alcuni programmatori provengono dai primi giorni di BASIC, dove un nome variabile può contenere 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 preoccuparsi di SomeNameessere accidentalmente uguali SOMENAMEe causare un bug a causa di cose del genere.