Parole chiave senza distinzione tra maiuscole e minuscole in una lingua [chiuso]

Stiamo cercando di scrivere un linguaggio di scripting personalizzato. C'è stato un suggerimento per far perdonare la lingua fornendo parole chiave senza distinzione tra maiuscole e minuscole .

Personalmente non mi piace l'idea, ma ci sono poche persone nella mia squadra che si sporgono verso di essa, dicendo che renderà felice l'utente finale! Esempi di linguaggi come FORTRAN, BASIC, SQL vengono forniti dicendo che non fanno distinzione tra maiuscole e minuscole.

E '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, allora la distinzione tra maiuscole e minuscole è probabilmente la cosa giusta da fare, perché è quello che l'utente si aspetta. Ma per la maggior parte degli utenti finali, anche per gli utenti esperti, questo sarà confuso.

VB / VBA / VBScript non fanno distinzione tra maiuscole e minuscole e questa è stata una decisione presa per consentire ai non programmatori di imparare facilmente il linguaggio. Le formule di Excel, non esattamente degli script ma vicine quanto molti utenti ottengono, non fanno distinzione tra maiuscole e minuscole. Nella maggior parte dei casi la scelta del caso può rendere il testo più o meno professionale e raffinato, ma il caso stesso non cambierà il significato semantico delle parole. Ecco perché credo che i non sviluppatori saranno confusi da un linguaggio di scripting maiuscolo / minuscolo.

Ancora una volta, questa non è una scelta tecnica. È una scelta di gestione del prodotto che deve essere fatta da persone che conoscono bene il pubblico target.

Dovresti decidere in base all'esperienza utente che desideri presentare, non a quanto sia facile o difficile implementare.

Se renderà più facile per i tuoi utenti l'insensibilità ai casi, questo è ciò che dovresti implementare.

Ad esempio, SQL non fa distinzione tra maiuscole e minuscole. Questo lo rende molto facile da usare in un ambiente interattivo.

Un altro modo di vedere questo è che ci sarà mai una differenza tra keyworde Keywordnella 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 fare distinzione tra maiuscole e minuscole, punto. Le persone possono adattarsi a questo molto facilmente: devono semplicemente ricordarsi di lavorare principalmente in lettere minuscole e fare attenzione agli identificatori a maiuscole o minuscole nelle API esistenti.

Una volta sembrava ovvio rendere le lingue insensibili alle maiuscole. Questo perché le lettere minuscole non erano disponibili su tutti i sistemi di elaborazione e sui loro dispositivi I / O (tastiere, stampanti e dispositivi di visualizzazione). Le implementazioni del linguaggio di programmazione dovevano accettare programmi scritti in maiuscolo, poiché solo quello poteva essere visualizzato o stampato. E per questo dovevano fare distinzione tra maiuscole e minuscole, perché accettare maiuscole e allo stesso tempo fare distinzione tra maiuscole e minuscole. Le lettere minuscole erano qualcosa che i programmatori volevano, ma non potevano sempre avere. Nessuno voleva davvero lavorare con programmi che gridavano in maiuscolo; era solo una limitazione hardware.

Per un po ', era comune persino piegare i casi nei terminali. Se un terminale fosse in grado di visualizzare solo lettere maiuscole, ma è stato necessario accedere a un sistema di elaborazione che supporta le lettere maiuscole e minuscole, il terminale piegherebbe le lettere minuscole in maiuscole. Pensi che fosse tanto tempo fa? "Come l'Apple II, l'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 con contenuto in maiuscolo, l'emulatore di terminale (o host) doveva ripiegare tutto in maiuscolo. A quei tempi i messaggi scritti in maiuscolo erano comuni nelle bacheche. Questa funzionalità si trova ancora nei sistemi operativi simili a Unix, come il kernel Linux. Ad esempio, digitare stty olcucal prompt della shell.La disciplina della linea tty Unix può mappare lettere minuscole in maiuscolo sull'output e può mappare lettere maiuscole in maiuscolo sull'input. Ciò consente di lavorare con un linguaggio di programmazione minuscolo, su un terminale che non ha lettere minuscole.

L'insensibilità alle maiuscole è un concetto obsoleto di un'era passata del computer che non funziona molto bene nel moderno mondo dell'informatica internazionalizzata. Lo estendi in altre lingue? Che ne dici del francese: consideri È ed è equivalente? O giapponese? Consideri hiragana e katakana solo casi, in modo che フ ァ イ ル e ふ ぁ い る siano lo stesso identificatore? Il supporto per tale follia complicherà notevolmente il tuo analizzatore lessicale, che dovrà avere mappe di equivalenza dei casi per l'intero spazio Unicode.

Nota che la matematica fa distinzione tra maiuscole e minuscole. Ad esempio, il sigma in maiuscolo potrebbe indicare la somma, mentre il sigma in minuscolo indica qualcos'altro, come la deviazione standard. Ciò può verificarsi nella stessa formula senza creare alcuna difficoltà. (Il linguaggio di programmazione renderà Σ e σ equivalenti?)

L'ortografia inglese è sensibile. Ad esempio, molti nomi propri corrispondono ai 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 è l'acronimo di test scolastico attitudinale, mentre "sat" è il participio passato di "sit". Le persone intelligenti prestano attenzione ai dettagli e capitalizzano correttamente.

Fondamentalmente, qualsiasi nuovo linguaggio di programmazione creato dal 1985, che non fa distinzione tra maiuscole e minuscole, è PER QUELLI CHE TI SONO ANCORA DOVUTI NELLE E-MAIL E NELLE POSTE SENZA UN SECONDO PENSIERO.

Che cosa succede se la tua lingua viene mai utilizzata come obiettivo di generazione del codice per tradurre il codice in un'altra lingua e tale altra lingua fa distinzione tra maiuscole e minuscole? Dovrai in qualche modo trasformare tutti i nomi per catturare la distinzione. (Quindi affermare che questa non è una decisione tecnica, e solo una questione di 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 distinzione tra maiuscole e minuscole hanno un problema con i dati esterni che non fanno distinzione tra maiuscole e minuscole.

Il Lisp comune ha colpito 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, FOOe Footutto denotano lo stesso simbolo: il simbolo 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 il caso o conservarlo. Le ultime due scelte danno origine a un dialetto con distinzione tra maiuscole e minuscole. In questo modo, gli utenti hanno la massima flessibilità.

Il vero fattore determinante è la frequenza con cui vuoi avere più cose con lo stesso nome. La distinzione tra maiuscole e minuscole funziona in SQL perché spesso non si desidera una colonna denominata SELECT. Sarebbe fastidioso in Java perché assomiglia a ogni altra riga Object object = new Object(), dove 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 il sovraccarico è utile soprattutto in progetti grandi e complessi. Per un uso più frequente, come un linguaggio di scripting, l'insensibilità al maiuscolo / minuscolo può rendere la programmazione molto più semplice.

Una volta ho creato un linguaggio di regole in cui gli identificatori non erano solo insensibili alle maiuscole, ma erano insensibili agli spazi bianchi. Ho anche permesso di creare alias che si riferivano allo stesso identificatore. Ad esempio, ProgrammersStackExchange, scambio programmatore di stack e PSE si sono risolti tutti con lo stesso simbolo esatto e potevano essere usati in modo intercambiabile.

Per il mio dominio ha funzionato molto bene, perché il dominio aveva molti modi estremamente noti per fare riferimento alla stessa cosa e i conflitti di denominazione erano rari. Nessuno sarebbe sorpreso digitando una query usando un nome e facendo sì che il risultato ne usasse un altro. Avere il supporto linguistico ha reso molto semplice la traduzione tra il dominio e il linguaggio di programmazione. Tuttavia, ha anche reso più difficili alcune attività, come trovare tutti i riferimenti a una variabile. Per fortuna, nel mio caso quel tipo di situazioni o raramente si presentava, o era abbastanza facile costruire un supporto strumenti per aiutare, ma devi tenere conto della tua situazione.

Supponiamo che il tuo linguaggio di script faccia distinzione tra maiuscole e minuscole - hai intenzione di creare un compilatore o un controllo della sintassi che dirà all'utente se fa un refuso usando il caso sbagliato in un nome di variabile o una parola chiave? Altrimenti, questo sarebbe un argomento molto forte per rendere insensibile il caso linguistico.

Puoi dichiarare le variabili al volo? In tal caso, vorrei contestare la distinzione tra maiuscole e minuscole, poiché rintracciare un bug causato da

ATypo = 42; 

al contrario di

Atypo = 42; 

chiede inutilmente tempo per il debug, quando avere le due affermazioni equivalenti semplifica la vita.

Esempi di linguaggi come FORTRAN, BASIC, SQL vengono forniti dicendo che non fanno distinzione tra maiuscole e minuscole.

Il motivo per cui FORTRAN e SQL (e COBOL) non fanno distinzione tra maiuscole e minuscole è che sono stati originariamente progettati per l'uso su macchine in cui i normali set di caratteri avevano solo lettere maiuscole. L'insensibilità alle maiuscole / minuscole in quelle lingue (almeno) è più un artefatto storico che una scelta di design del linguaggio.

Ora potresti argomentare che l'insensibilità del caso è più indulgente, ma il rovescio della medaglia è che la sensibilità del caso si traduce in un codice più leggibile perché DOVREBBE DOVREBBE UTILIZZARE ACCENDERE ATTIVITÀ.

La sensibilità del caso è considerata dannosa.

La vita non fa distinzione tra maiuscole e minuscole e nemmeno utenti o programmatori.

I linguaggi sensibili al maiuscolo / minuscolo sono un incidente storico, di sistemi vincolati che hanno reso difficili i confronti senza distinzione tra maiuscole e minuscole. Questo handicap non esiste più, quindi non c'è motivo di rendere mai più un sistema sensibile al maiuscolo / minuscolo.

Vorrei dire che la distinzione tra maiuscole e minuscole è malefica , poiché mette la comodità del computer davanti a quella dell'utente.

(Riferito, ricordo qualche anno fa, un genio si rifiutò di pagare la fattura della sua carta di credito perché il suo nome era in maiuscolo, ma ha scritto il caso misto. Pertanto, ha sostenuto, non era indirizzato correttamente a lui e non lo era una richiesta di pagamento valida. Il giudice ha trattato l'argomento come meritava).

Dalla mia esperienza personale non vedo grandi differenze tra linguaggi sensibili al maiuscolo / minuscolo e insensibili.

La cosa più importante sono le convenzioni di denominazione e strutturali che un programmatore dovrebbe mantenere nel suo codice e nessun compilatore o parser lo controlla per lui. Se ti attieni a un qualche tipo di regole, saprai facilmente un nome proprio (non penserai se hai nominato una variabile checkOut o CheckOut) e il tuo codice probabilmente sarà sensibile al maiuscolo / minuscolo 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ù dolorosa la comprensione di 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, vedrai ad esempio:

CheckOut.getInstance () - è un metodo statico di una classe chiamata checkOut.calculate () - è un metodo di un oggetto tenuto in un campo variabile o pubblico chiamato _checkOut.calculate () - è un metodo di un oggetto tenuto in un campo privato chiamato CHECKOUT - è un campo / variabile statico o costante finale

senza estrarre alcuni altri file o parti di un file. Rende più veloce la lettura del codice.

Vedo molti sviluppatori che usano regole simili - in linguaggi che uso spesso: Java, PHP, Action Script, JavaScript, C ++.

In rari casi si potrebbe essere arrabbiati per la distinzione tra maiuscole e minuscole, ad esempio quando si desidera utilizzare CheckOut per un nome di classe e checkOut per una variabile e non è possibile perché si scontrano tra loro. Ma è un problema di un programmatore che viene utilizzato per la distinzione tra maiuscole e minuscole e per usarlo nelle sue convenzioni di denominazione. Si possono avere regole con prefissi standard o postfissi in un linguaggio senza distinzione tra maiuscole e minuscole (non programma in VB ma so che molti programmatori VB hanno questo tipo di convenzioni di denominazione).

In poche parole: vedo meglio la distinzione tra maiuscole e minuscole (solo per linguaggi orientati agli oggetti) perché la maggior parte degli sviluppatori usa linguaggi con distinzione tra maiuscole e minuscole e la maggior parte usa convenzioni di denominazione basate sulla distinzione tra maiuscole e minuscole, quindi vorrebbero che una lingua fosse sensibile alle maiuscole e minuscole in grado di attenersi alle loro regole senza una sorta di modifiche. Ma è un argomento piuttosto religioso - non oggettivo (non basato su svantaggi reali o lati positivi della sensibilità del caso) perché non ne vedo nessuno quando si tratta di un buon sviluppatore, quando si tratta di un DeVeLoPeR bAd si potrebbe produrre un codice da incubo anche quando c'è la sensibilità del caso, quindi non è una grande differenza).

I linguaggi di programmazione dovrebbero distinguere tra maiuscole e minuscole.

La ragione principale per cui così tante lingue in questi giorni fanno distinzione tra maiuscole e minuscole è semplicemente il design del linguaggio di culto: "C lo ha fatto in questo modo, e C è incredibilmente popolare, quindi deve essere giusto". E come in molte altre cose, C ha sbagliato in modo evidente questo.

Questo è in realtà parte della filosofia alla base di C e UNIX: se hai una scelta tra una cattiva soluzione che è facile da implementare e una buona soluzione che è più difficile da implementare, scegli la cattiva soluzione e spingi l'onere di aggirare il tuo casino su l'utente. Questo può sembrare snark, ma è assolutamente vero. È noto come il "principio del peggio è meglio", ed è stato direttamente responsabile di danni per miliardi di dollari negli ultimi decenni a causa del C e del C ++ che rende fin troppo facile scrivere software glitch e insicuro.

Rendere insensibile alle maiuscole delle lingue è decisamente 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 insensibile alle maiuscole. Ma è anche una cattiva idea, per due motivi:

• Innanzitutto, specialmente se stai costruendo un linguaggio di scripting, un semplice errore di battitura in cui chiami qualcosa "myObject" in un posto e "MyObject" in un altro, dove ovviamente ti riferisci allo stesso oggetto ma sei solo un po 'incoerente con la maiuscola , non si trasforma in un errore di runtime. (Questo è famigerato come un grave punto di dolore nei linguaggi di scripting che sbagliano, come Python.)
• In secondo luogo, non avere la distinzione tra maiuscole e minuscole significa che non si può abusare della distinzione tra maiuscole e minuscole perché la stessa parola si riferisce a due cose diverse nello stesso ambito semplicemente modificando la capitalizzazione. Se hai mai dovuto lavorare con il codice di Windows in un ambiente C e imbatterti in brutte dichiarazioni come HWND hwnd;, saprai esattamente di cosa sto parlando. Le persone che scrivono in questo modo dovrebbero essere eliminate e colpite, e rendere insensibile il maiuscolo / minuscolo del linguaggio impedisce che l'abuso di maiuscole e minuscole si diffonda nel tuo codice.

Quindi fai lo sforzo extra per farlo bene. Il codice risultante sarà più pulito, più facile da leggere, meno buggy e renderà i tuoi utenti più produttivi, e non è l'obiettivo finale di alcun linguaggio di programmazione?

Non riesco a credere che qualcuno abbia detto "la distinzione tra maiuscole e minuscole semplifica la lettura del codice".

Certamente no! Ho guardato alle spalle di un collega le variabili denominate Azienda e azienda (Azienda variabile pubblica, società variabile privata abbinata) e la sua scelta di carattere e colore rende incredibilmente difficile distinguere tra i due, anche uno accanto all'altro.

L'istruzione corretta dovrebbe essere "maiuscole e minuscole rendono più semplice la lettura del codice". Questa è una verità molto più ovvia - ad es. Variabili chiamate CompanyName e CompanyAddress piuttosto che companyname. Ma nessun linguaggio che conosco ti fa usare solo nomi di variabili minuscole.

La convenzione più folle che io conosca è quella "maiuscola pubblica, minuscola privata". Sta solo chiedendo problemi!

La mia opinione sugli errori è "meglio che qualcosa fallisca rumorosamente e il più presto possibile invece che fallire silenziosamente ma sembra avere successo". E non c'è prima del tempo di compilazione.

Se si utilizza erroneamente una variabile minuscola quando si intendeva utilizzare la maiuscola, verrà spesso compilata se la si fa riferimento all'interno della stessa classe . Pertanto, è possibile sembrare avere esito positivo sia in fase di compilazione che in fase di esecuzione, ma essere sottilmente facendo la cosa sbagliata e forse non rilevarla per molto tempo. Quando rilevi che c'è qualcosa che non va

È molto meglio usare una convenzione in cui la variabile privata ha un suffisso, ad esempio variabile pubblica dell'azienda, variabile privata dell'aziendaP. Nessuno mescolerà accidentalmente i due e appariranno insieme nell'intellisense.

Ciò contrasta con un'obiezione che la gente deve alla notazione ungherese, in cui una variabile privata prefissata pCompany non apparirebbe in un buon posto nell'intellisesne.

Questa convenzione presenta tutti i vantaggi della terribile convenzione maiuscola / minuscola e nessuno dei suoi svantaggi.

Il fatto che le persone sentano il bisogno di fare appello alla sensibilità del case per distinguere tra variabili mostra sia una mancanza di immaginazione che una mancanza di buon senso, secondo me. O, purtroppo, alle pecore umane piace l'abitudine di seguire una convenzione perché "è così che è sempre stata fatta"

Rendi le cose con cui lavori chiaramente e ovviamente diverse l'una dall'altra, anche se sono correlate !!

Non dovresti introdurre insensibilità ai casi senza un'ottima ragione per farlo. Ad esempio, gestire i confronti di casi con Unicode può essere una cagna. La distinzione tra maiuscole e minuscole (o la loro mancanza) delle lingue più vecchie è irrilevante, poiché i loro bisogni erano molto diversi.

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 più facile da leggere l'uso corretto del caso misto .

• Permette / incoraggia CamelCase in modo tale che la stessa parola con un caso diverso possa riferirsi a cose correlate: Car car; Quindi la variabile nominata carviene creata 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 insensibile al maiuscolo / minuscolo.

• Se la lingua verrà interpretata, potrebbe esserci una penalità di prestazione per l'analisi insensibile del codice.

• Che dire dei personaggi non inglesi? Stai decidendo ora di non supportare mai copta, cinese e hindi? Ti consiglio vivamente di rendere tutto predefinito la tua lingua su UTF-8 e che supporta alcune lingue che hanno caratteri senza equivalente maiuscolo o minuscolo. Non userai questi caratteri nelle tue parole chiave, ma quando inizi a disattivare la distinzione tra maiuscole e minuscole in vari strumenti (per esempio per trovare cose nei file), 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 lo fa.

D'altra parte, tutto ciò che rende felice l'utente finale porta un po 'di luce nel mondo. Se influirà davvero sulla felicità dell'utente, allora devi farlo.

Se vuoi renderlo davvero semplice per gli utenti finali, puoi fare di meglio della maiuscola / insensibilità - dai un'occhiata a Scratch ! Qualche gatto in meno con i cartoni animati e colori più adatti al lavoro e hai la lingua più amichevole che abbia mai visto - e non devi scrivere nulla! Solo un pensiero.