Stiamo provando a scrivere un linguaggio di scripting personalizzato. C'è stato un suggerimento per rendere la lingua indulgente fornendo parole chiave case insensitive .
Personalmente non mi piace l'idea, ma ci sono poche persone nella mia squadra che si appoggiano ad essa, dicendo che renderà felice l'utente finale! Esempi di linguaggi come FORTRAN, BASIC, SQL vengono forniti dicendo che questi sono case insensitive.
Questa è una buona idea?
Chiediti chi è l'utente finale. Se è pensato per essere scritto da qualcuno con esperienza di programmazione in C o Javscript, o esperienza IT in Unix, quindi la distinzione tra maiuscole e minuscole è probabilmente la cosa giusta da fare, perché è ciò che l'utente si aspetta. Ma per la maggior parte degli utenti finali, anche per gli utenti esperti, ciò potrebbe creare confusione.
VB / VBA / VBScript non fanno distinzione tra maiuscole e minuscole, e questa è stata una decisione presa per consentire ai non programmatori di ottenere facilmente il blocco della lingua. Le formule di Excel, non esattamente gli script ma il più vicino possibile a molti utenti, non fanno distinzione tra maiuscole e minuscole. Nella maggior parte degli scritti la scelta del caso può rendere il testo più o meno professionale e raffinato, ma il caso non cambierà il significato semantico delle parole. Ecco perché credo che i non sviluppatori saranno confusi da un linguaggio di scripting case sensitive.
Ancora una volta, questa non è una scelta tecnica. È una scelta di gestione del prodotto che deve essere fatta dalle persone che conoscono bene il target di riferimento.
Dovresti decidere in base all'esperienza utente che desideri presentare, non a quanto sia facile o difficile da implementare.
Se renderà più facile per i tuoi utenti avere insensibilità alle maiuscole e minuscole, allora è quello che dovresti implementare.
Come nel caso in cui SQL non fa distinzione tra maiuscole e minuscole. Questo lo rende molto facile da usare in un'impostazione interattiva.
Un altro modo per vedere questo è che ci sarà mai una differenza tra keyword e Keyword nella tua lingua, e questa differenza sarà significativa per l'utente? Per un linguaggio di scripting direi che la risposta è "no".
I linguaggi di programmazione dovrebbero essere case-sensitive, period. Le persone possono adattarsi a questo molto facilmente: devono semplicemente ricordare di lavorare principalmente in minuscolo e di prestare attenzione agli identificatori con maiuscole o minuscole nelle API esistenti.
Una volta sembrava ovvio rendere le lingue insensibili alle maiuscole. Questo perché la minuscola non era disponibile su tutti i sistemi di elaborazione e i relativi dispositivi I / O (tastiere, stampanti e dispositivi di visualizzazione). Le implementazioni linguistiche di programmazione dovevano accettare programmi scritti in maiuscolo, poiché solo quello poteva essere visualizzato o stampato. E per questo dovevano essere insensibili alle maiuscole e minuscole, perché accettare maiuscole e minuscole e essere case sensitive allo stesso tempo significa rifiutare le minuscole. La minuscola era qualcosa che i programmatori volevano, ma non poteva sempre avere. Nessuno voleva davvero lavorare con i programmi che urlavano in maiuscolo; era solo una limitazione hardware.
Da un po 'di tempo, era comune persino fare piegare il caso nei terminali. Se un terminale poteva visualizzare solo lettere maiuscole, ma si doveva accedere a un sistema informatico che supportava lettere maiuscole e minuscole, il terminale avrebbe piegato la lettera minuscola alla maiuscola. Pensi che sia stato tanto tempo fa? "Come Apple II, Apple II Plus non aveva funzionalità minuscole." (http://en.wikipedia.org/wiki/Apple_II_Plus) Quando gli utenti dei primi computer Apple componevano un BBS che aveva contenuto di maiuscole e minuscole, l'emulatore di terminale (o host) ha dovuto piegare tutto in maiuscolo. I messaggi scritti in maiuscolo erano comuni nelle bacheche in quei giorni. Questa funzionalità è ancora presente nei sistemi operativi di tipo Unix, come il kernel Linux. Ad esempio, digita stty olcuc al prompt della shell. La disciplina della linea tty Unix può mappare minuscole a maiuscole sull'output e può mappare lettere maiuscole e minuscole su input. Ciò ti consente di lavorare in un linguaggio di programmazione in minuscolo, su un terminale che non ha maiuscole.
L'insensibilità alle maiuscole / minuscole è un concetto obsoleto di un'era dei computer passati che non funziona molto bene nel mondo moderno dell'informatica internazionalizzata. Lo estendi in altre lingue? Che ne dici di francese: consideri È ed è equivalente? O giapponese? Consideri hiragana e katakana solo come casi, in modo che フ ァ イ ル e ふ ぁ い る siano identici? Il supporto per tale follia complicherà notevolmente il tuo analizzatore lessicale, che dovrà avere mappe di equivalenza del caso per l'intero spazio Unicode.
Si noti che la matematica è case sensitive. Per esempio, il sigma maiuscolo potrebbe denotare la somma, mentre il sigma minuscolo denota qualcos'altro, come la deviazione standard. Questo può accadere nella stessa formula senza creare alcuna difficoltà. (Il linguaggio di programmazione sarà Σ e σ equivalente?)
L'ortografia inglese è sensibile. Ad esempio, molti nomi propri corrispondono a nomi ordinari o anche ad altre parti del discorso. "may" è un verbo, ma "May" è un mese o il nome di una donna. Inoltre, se un acronimo o un'abbreviazione è scritto in minuscolo, può essere fonte di confusione. SAT sta per test attitudinale scolastico, mentre "sat" è il participio passato di "sit". Le persone intelligenti prestano attenzione ai dettagli e capitalizzano correttamente.
Fondamentalmente, ogni nuovo linguaggio di programmazione creato dal 1985 che non fa distinzione tra maiuscole e minuscole è PER COLORO CHE NON HANNO ANCORA MAIL NELLE E-MAIL E SUGGERIMENTI SENZA UN SECONDO PENSIERO.
Che cosa succede se la tua lingua viene mai utilizzata come target di generazione del codice per tradurre il codice in un'altra lingua e che l'altra lingua è sensibile al maiuscolo e al minuscolo? Dovrai in qualche modo trasformare tutti i nomi per catturare la distinzione. (Quindi affermare che questa non è una decisione tecnica, e solo questione delle preferenze emotive del pubblico target, è ridicolo.)
Guarda i fastidiosi problemi causati dalla gestione dei casi in Windows, quando i file vengono importati da un altro sistema operativo. Questo è un problema tecnico. I file system con maiuscole e minuscole hanno un problema con i dati estranei che quelli con distinzione tra maiuscole e minuscole non lo fanno.
Common Lisp ha trovato l'approccio ideale: i nomi dei simboli fanno distinzione tra maiuscole e minuscole, ma quando i token vengono letti, vengono piegati in maiuscolo. Ciò significa che i token foo , fOO , FOO e Foo indicano tutti lo stesso simbolo: il simbolo il cui nome è memorizzato come stringa di caratteri "FOO" . Inoltre, questo comportamento è solo la configurazione predefinita della tabella di lettura. Il lettore può piegare le lettere in maiuscolo, in minuscolo, invertire la custodia o conservarla. Le ultime due scelte danno origine a un dialetto case-sensitive. In questo modo, gli utenti hanno la massima flessibilità.
Il vero fattore determinante è la frequenza con cui vorrai avere più cose con lo stesso nome. L'insensibilità alle maiuscole e minuscole funziona in SQL perché spesso non si desidera una colonna denominata SELECT . Sarebbe fastidioso in Java perché ogni altra riga sembra Object object = new Object() , in cui si desidera che lo stesso nome faccia riferimento a una classe, un'istanza e un costruttore.
In altre parole, la distinzione tra maiuscole e minuscole è utile soprattutto per sovraccaricare un nome e l'overloading è utile soprattutto in progetti grandi e complessi. Per un uso più raro, ad esempio un linguaggio di scripting, l'insensibilità alle maiuscole e minuscole può rendere la programmazione molto più semplice.
Ho creato un linguaggio delle regole quando gli identificatori non erano solo insensibili alle maiuscole e minuscole, erano insensibili agli spazi bianchi. Ho anche permesso di creare alias che si riferivano allo stesso identificatore. Ad esempio, ProgrammersStackExchange, programmatori stack exchange e PSE sono tutti risolti con lo stesso simbolo e potrebbero essere utilizzati in modo intercambiabile.
Per il mio dominio ha funzionato molto bene, perché il dominio aveva molti modi estremamente noti per riferirsi alla stessa cosa, e i conflitti di denominazione erano rari. Nessuno sarebbe sorpreso digitando una query usando un nome e avendo il risultato ne usa un altro. Avere supporto linguistico ha reso la traduzione tra il dominio e il linguaggio di programmazione molto facile. Tuttavia, ha anche reso più difficili alcune attività, come trovare tutti i riferimenti a una variabile. Fortunatamente, nel mio caso, raramente si verificavano situazioni di questo tipo o erano abbastanza facili da costruire il supporto degli strumenti per aiutare, ma è necessario tenere conto della propria situazione.
Supponendo che il tuo linguaggio di script sia sensibile al maiuscolo / minuscolo - hai intenzione di creare un compilatore o un verificatore di sintassi che dirà all'utente se fa un refuso utilizzando il caso sbagliato in un nome di variabile o una parola chiave? In caso contrario, sarebbe un argomento molto strong per rendere insensibile il caso della lingua.
Puoi dichiarare le variabili al volo? In tal caso, vorrei discutere contro la distinzione tra maiuscole e minuscole, come rintracciare un errore causato da
ATypo = 42;
al contrario di
Atypo = 42;
chiede inutilmente il tempo di debug, quando avere le due dichiarazioni equivalenti rende solo la vita più facile.
Examples of languages like FORTRAN, BASIC, SQL are given saying that these are case insensitive.
Il motivo per cui FORTRAN e SQL (e COBOL) non fanno distinzione tra maiuscole e minuscole è che sono stati originariamente progettati per essere utilizzati su macchine in cui i set di caratteri normali avevano solo lettere maiuscole. L'insensibilità alle maiuscole e minuscole in quelle lingue (almeno) è più un artefatto storico che una scelta di progettazione linguistica.
Ora potresti argomentare che la maiuscola e la minuscola sono più tolleranti, ma il rovescio della medaglia è che la distinzione tra maiuscole e minuscole si traduce in un codice più leggibile perché crea il cOdErO per cOnSIZIARE cApItAlIzIoNE.
La vita non è case sensitive e nemmeno utenti o programmatori.
I linguaggi case sensitive sono un incidente storico, di sistemi vincolati che hanno trovato difficili i confronti insensibili alle maiuscole. Questo handicap non esiste più, quindi non c'è motivo di rendere mai più un sistema di computer case-sensitive.
Direi che maiuscole e minuscole è male , poiché mette la comodità del computer prima di quella dell'utente.
(Riferito, alcuni anni fa, ricordo che qualche genio si rifiutò di pagare il conto della sua carta di credito perché il suo nome era in maiuscolo, ma scrisse un caso misto, quindi sostenne che non era indirizzato a lui e non era una richiesta di pagamento valida. Il Giudice trattava l'argomento come meritava).
Dalla mia esperienza personale non vedo una grande differenza tra i maiuscole e i linguaggi insensibili.
La cosa più importante è la denominazione e le convenzioni strutturali che un programmatore dovrebbe tenere nel suo codice e nessun compilatore o parser lo controlla per lui. Se ti attieni a qualche tipo di regole, conoscerai facilmente un nome appropriato (non penserai se hai nominato una variabile checkOut o CheckOut) e il tuo codice probabilmente sarà case sensitive e più facile da leggere.
Non si dovrebbe usare CheckOut e checkOut e checkout e cHeCkOuT e CHECKOUT nello stesso significato. Ciò danneggerà la leggibilità e renderà più comprensibile quel tipo di codice (ma ci sono cose peggiori che si possono fare per distruggere la leggibilità del codice).
Se usi qualche tipo di regole che vedrai a colpo d'occhio, per esempio:
CheckOut.getInstance () - è il metodo statico di una classe chiamata checkOut.calculate () - è un metodo di un oggetto tenuto in campo variabile o pubblico chiamato _checkOut.calculate () - è un metodo di un oggetto tenuto in un campo privato chiamato CHECKOUT - è un finale statico o costante campo / variabile
senza verificare altri file o parti di un file. Rende più veloce la lettura del codice.
Vedo molti sviluppatori che usano regole simili - in lingue che uso spesso: Java, PHP, Action Script, JavaScript, C ++.
In un raro caso si potrebbe essere arrabbiati con insensibilità alle maiuscole / minuscole, ad esempio quando si desidera utilizzare CheckOut per un nome classe e checkOut per una variabile e non è possibile perché si scontra l'uno con l'altro. Ma è un problema di un programmatore che viene utilizzato per la distinzione tra maiuscole e minuscole e per utilizzarlo nelle convenzioni di denominazione. Si possono avere regole con prefissi standard o postfix in un linguaggio non sensibile al maiuscolo / minuscolo (non programma in VB ma so che molti programmatori VB hanno questo tipo di convenzioni di denominazione).
In poche parole: vedo meglio la case sensitive (solo per linguaggi object oriented) perché la maggior parte degli sviluppatori usa linguaggi case sensitive e la maggior parte di essi usa convenzioni di denominazione basate sulla distinzione tra maiuscole e minuscole, quindi preferirebbero che una lingua sia sensibile al maiuscolo e minuscolo sarebbero in grado di attenersi alle loro regole senza alcune modifiche. Ma è un argomento piuttosto religioso - non oggettivo (non basato su reali inconvenienti o buoni lati della sensibilità del caso - perché non ne vedo quando si tratta di un buon sviluppatore, quando si tratta di un DeVeLoPeR bAd si può produrre codice di incubo anche quando c'è la sensibilità del caso, quindi non è una grande differenza.
I linguaggi di programmazione dovrebbero essere senza distinzione tra maiuscole e minuscole.
Il motivo principale per cui così tante lingue al giorno d'oggi sono sensibili alle maiuscole e minuscole è semplicemente il design linguistico del cargo: "C l'ha fatto in quel modo, e C è incredibilmente popolare, quindi deve essere giusto." E come in tante altre cose, C ha dimostrato che questo è chiaramente sbagliato.
Questo è in realtà parte della filosofia di guida di C e UNIX: Se hai una scelta tra una cattiva soluzione facile da implementare e una buona soluzione che è più difficile da implementare, scegli la soluzione sbagliata e spingi l'onere di aggirare il tuo pasticcio con l'utente. Questo potrebbe sembrare uno snark, ma è assolutamente vero. È noto come il "peggio è un principio migliore" ed è stato direttamente responsabile di miliardi di dollari di danni negli ultimi decenni a causa di C e C ++ che rendono fin troppo facile scrivere software glitchy e insicuro.
Rendere insensibile un caso linguistico è sicuramente più semplice; non è necessario il lexer, il parser e le tabelle dei simboli per fare il lavoro extra per assicurarsi che tutto corrisponda in modo non sensibile al maiuscolo / minuscolo. Ma è anche una cattiva idea, per due motivi:
HWND hwnd; , saprai esattamente di cosa sto parlando. Le persone che scrivono in quel modo dovrebbero essere tolti e fucilati, e rendere insensibile il caso linguistico impedisce che l'abuso di maiuscole e minuscole si inserisca nel tuo codice. Quindi fai lo sforzo in più per farlo bene. Il codice risultante sarà più pulito, più facile da leggere, meno buggato e renderà i tuoi utenti più produttivi e non è l'obiettivo finale di qualsiasi linguaggio di programmazione?
Non posso credere che qualcuno abbia detto che "la distinzione tra maiuscole e minuscole rende più semplice la lettura del codice".
Di certo non lo è! Ho guardato le spalle di un collega a variabili denominate Società e società (società a variabile pubblica, società a variabili private abbinate) e la sua scelta di caratteri e colori rende incredibilmente difficile distinguere le due, anche una accanto all'altra.
La frase corretta dovrebbe essere "caso misto rende più facile leggere il codice". Questa è una verità molto più ovvia, ad es. variabili chiamate CompanyName e CompanyAddress piuttosto che companyname. Ma nessuna lingua che conosco ti fa usare solo nomi di variabili minuscole.
La convenzione più folle che conosco è quella del "privato maiuscolo, minuscolo privato". Sta solo chiedendo guai!
La mia interpretazione degli errori è "meglio che qualcosa fallisca rumorosamente e al più presto, piuttosto che fallire silenziosamente, ma sembra riuscire". E non c'è prima del tempo di compilazione.
Se per errore usi una variabile minuscola quando intendi usare la maiuscola, spesso compila se fai riferimento alla stessa classe . Quindi, puoi sembrare avere successo sia nel tempo di compilazione che in quello di esecuzione, ma stai facendo in modo subdolo la cosa sbagliata, e forse non lo rilevi da molto tempo. Quando rilevi che c'è qualcosa di sbagliato
Molto meglio usare una convenzione in cui la variabile privata ha un suffisso - ad es. Variabile pubblica dell'azienda, variabile privata CompanyP. Nessuno sta per accidentalmente mescolare i due, e compaiono insieme nell'intelligenza.
Ciò contrasta con un'obiezione che le persone hanno sulla notazione ungherese, in cui una variabile privata prefissa pCompany non apparirebbe in un buon posto nell'intelligene.
Questa convenzione ha tutti i vantaggi della terribile convenzione maiuscola / minuscola e nessuno dei suoi inconvenienti.
Il fatto che le persone sentano il bisogno di fare appello alla distinzione tra maiuscole e minuscole per distinguere tra variabili mostra a mio avviso sia una mancanza di immaginazione che una mancanza di buon senso. O, purtroppo, l'abitudine delle pecore umane di seguire una convenzione perché "così è sempre stato fatto"
Rendi le cose con cui lavori chiaramente e ovviamente diverse l'una dall'altra, anche se sono correlate !!
Non dovresti introdurre maiuscole e minuscole senza una buona ragione per farlo. Ad esempio, trattare i confronti tra maiuscole e minuscole con Unicode può essere una cagna. La case sensitive (o la sua mancanza) di lingue più vecchie è irrilevante, in quanto le loro esigenze erano molto diverse.
I programmatori di questa era si aspettano la distinzione tra maiuscole e minuscole.
La distinzione tra maiuscole e minuscole rende il codice più leggibile e la programmazione più semplice.
Le persone trovano l'uso corretto del caso misto più facile da leggere .
Permette / incoraggia CamelCase in modo tale che la stessa parola con case diverse possa riferirsi a cose correlate: Car car; Così viene creata la variabile denominata car di tipo Car .
ALL_CAPS_WITH_UNDERSCORES indica le costanti per convenzione in molte lingue
all_lower_with_underscores può essere utilizzato per le variabili membro o qualcos'altro.
Tutti i moderni strumenti di programmazione (controllo del codice sorgente, editor, diff, grep, ecc.) sono progettati per la distinzione tra maiuscole e minuscole. Avrai sempre problemi con gli strumenti che i programmatori danno per scontato se fai un linguaggio senza distinzione tra maiuscole e minuscole.
Se la lingua verrà interpretata, potrebbe verificarsi una penalizzazione delle prestazioni per l'analisi senza distinzione tra maiuscole e minuscole del codice.
E i caratteri non inglesi? Decidi ora di non supportare mai Coptic, cinese e hindi? Ti suggerisco caldamente di impostare il tuo linguaggio predefinito su UTF-8 e supporta alcune lingue con caratteri senza equivalenti maiuscole o minuscole. Non utilizzerai questi caratteri nelle parole chiave, ma quando inizi a disattivare la distinzione tra maiuscole e minuscole in vari strumenti (per trovare elementi nei file, ad esempio), ti imbatterai in esperienze surreali e probabilmente spiacevoli.
Qual è il vantaggio? Le 3 lingue che menzioni sono degli anni '70 o precedenti. Nessun linguaggio moderno fa questo.
D'altro canto, tutto ciò che rende felice l'utente finale porta una piccola luce nel mondo. Se davvero avrà effetto sulla felicità dell'utente, allora devi farlo.
Se vuoi renderlo davvero semplice per gli utenti finali, puoi fare meglio di maiuscole / minuscole / insensibilità - dai un'occhiata a Scratch ! Un po 'meno gatti dei cartoni animati e colori più business-friendly e hai la lingua più amichevole che abbia mai visto - e non devi scrivere nulla! Solo un pensiero.