C'è un buon motivo per usare le maiuscole per le parole chiave SQL? [chiuso]

L'impostazione predefinita sembra essere maiuscola, ma c'è davvero qualche motivo per utilizzare le maiuscole per le parole chiave? Ho iniziato a utilizzare le maiuscole perché stavo solo cercando di abbinare ciò che SQL Server mi offre ogni volta che provo a creare qualcosa, come una nuova procedura memorizzata. Ma poi, mi sono sentito male per il mio bambino (5 °) dito, che ha sempre bisogno di tenere premuto il Shiftpulsante, quindi ho smesso di usare le maiuscole. Qual è il motivo per cui dovrei tornare alle maiuscole?

Modifica : grazie per le risposte ragazzi. Non programmavo ancora ai tempi in cui COBOL era il re, quindi non ne ero a conoscenza. Attaccherò con lettere minuscole da ora in poi.

È solo una questione di stile, probabilmente originaria ai tempi in cui gli editor non eseguivano la colorazione del codice.

Preferivo tutte le lettere maiuscole, ma ora sono incline verso tutte le lettere minuscole.

Personalmente, non mi piace il mio SQL che urla contro di me. MI RICORDA DI BASE O DI COBOL.

Quindi preferisco la mia minuscola T-SQL con i nomi degli oggetti del database MixedCase.

È molto più facile da leggere e spiccano valori letterali e commenti.

SQL È VECCHIO. IL CASO SUPERIORE STA GRIDANDO. Sembra strano e brutta.

Sebbene sia verosimilmente vero, nessuno di questi affronta i motivi speciali del linguaggio SQL per cui le parole chiave in maiuscolo sono una buona convenzione.

A differenza di molti linguaggi più recenti, SQL ha un gran numero di parole chiave e si affida alla capacità del lettore di distinguere parole chiave e identificatori per analizzare mentalmente la sintassi.

La risposta diretta alla tua domanda, quindi, è più una risposta a "perché il lettore di codice SQL trae così tanto vantaggio dalle parole chiave maiuscole, quando ciò non è vero per la maggior parte delle lingue moderne?":

• Fare affidamento sul mantenere le parole chiave nella propria testa è ragionevole per molte lingue moderne, ma irragionevole per SQL ; ha troppe parole chiave e troppe varianti.

• Affidarsi ai segni di punteggiatura è ragionevole per la maggior parte dei linguaggi moderni, ma irragionevole per SQL ; ne ha troppo pochi, invece dipende dall'ordine preciso delle parole chiave per indicare la sintassi.

• Fare affidamento su evidenziatori automatici per distinguere le parole chiave è ragionevole per le lingue moderne nei casi normali, ma ignora la realtà di ciò che gli evidenziatori possono ottenere per SQL . La maggior parte non copre tutte le parole chiave di tutte le varianti di SQL e, indipendentemente da ciò, SQL viene letto frequentemente e regolarmente in contesti in cui un evidenziatore non aiuta.

Questi sono alcuni dei motivi, specifici di SQL, per cui il lettore di codice SQL è meglio servito standardizzando le maiuscole per le parole chiave e usando solo identificativi non maiuscoli (cioè inferiori o misti).

L'evidenziazione a volte può aiutare. Ma solo se l'evidenziatore sa che hai SQL; e molto spesso abbiamo SQL in un contesto in cui l'editor / formatter non può ragionevolmente sapere che ha a che fare con SQL. Gli esempi includono query in linea, documentazione del programmatore e stringhe di testo all'interno del codice di un'altra lingua. Lo stesso non è vero ovunque vicino così spesso per linguaggi come Python o C ++; sì, il loro codice a volte appare in quei posti, ma non è fatto abitualmente come nel codice SQL.

Inoltre, il lettore utilizzerà comunemente un evidenziatore che conosce solo un sottoinsieme delle parole chiave utilizzate dall'implementazione SQL specifica. Molte delle parole chiave meno comuni non verranno evidenziate se non da una che conosce intimamente la tua variante SQL. Quindi il lettore, anche se sta usando un evidenziatore, ha ancora bisogno di un modo più diretto per distinguere le parole chiave in qualsiasi istruzione SQL moderatamente complessa.

Quindi il lettore frequentemente - e lo scrittore non può sapere in anticipo quando sarà - avrà bisogno del supporto del contenuto dell'istruzione SQL stessa, per sapere cosa intende lo scrittore come parola chiave e cosa si intende come identificatore. Quindi il contenuto SQL stesso deve distinguere le parole chiave per il lettore e l'uso di parole chiave maiuscole è il modo convenzionale e utile per farlo.

Gli esempi di Gordon Bell non sono esattamente corretti; in genere, vengono evidenziate solo le parole chiave, non l'intera query. Il suo secondo esempio sarebbe simile a:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Lo trovo molto più facile da leggere, dal momento che le parole chiave si distinguono di più. Anche con l'evidenziazione della sintassi, trovo l'esempio non capitalizzato molto più difficile da leggere.

Nella mia azienda, andiamo un po 'più in là con la nostra formattazione SQL.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

C'ERA UNA VOLTA QUANDO LA MAGGIOR PARTE DELLE PERSONE NON HA AVUTO LA POSSIBILITÀ DI ENTRARE NIENTE OLTRE LE LETTERE DEL CASO SUPERIORE PERCHÉ NON È STATA ANCORA INVENTATA LA RILEVANTE ENCODING (ASCII). SONO DISPONIBILI SOLO SEI BIT . MENTRE SQL PIÙ RECENTE, LE LETTERE DI CASI INFERIORI NON SONO STATE COMUNI ANCORA NELLA PROGRAMMAZIONE.

NOTA BENE CHE ALCUNE PERSONE RICHIEDONO CHE IL DATABASE OTTENERÀ UN SENSO DI URGENZA E GIRÀ LE VOSTRE DOMANDE PIÙ RAPIDAMENTE.

Meno del 10% delle lettere nel testo che leggiamo sono in maiuscolo. Quindi i nostri cervelli sono più desiderosi di riconoscere le lettere minuscole rispetto a quelle maiuscole. Gli studi hanno dimostrato che ci vuole più tempo per leggere il testo in maiuscolo. Ecco solo un esempio:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

L'esempio sopra, penso, sottolinea che anche quando parli di una o due parole, fa la differenza.

È perché SQL è un linguaggio così vecchio ( 1974 ) che quando è stato concepito, la maggior parte delle tastiere non aveva lettere minuscole! La documentazione linguistica rifletteva semplicemente la tecnologia del tempo.

La ricerca ha dimostrato che TUTTI I CAPS sono più difficili da leggere, al punto che la Federal Highway Administration degli Stati Uniti ha imposto l'uso di cartelli misti nel loro Manuale sui dispositivi di controllo uniforme del traffico, che afferma:

Le lettere per i nomi di luoghi, strade e autostrade sui cartelli stradali convenzionali devono essere una combinazione di lettere minuscole con lettere maiuscole iniziali.

Il New York Post ha anche pubblicato:

Gli studi hanno dimostrato che è più difficile leggere i segni di maiuscole e che quei millisecondi extra trascorsi a guardare lontano dalla strada hanno dimostrato di aumentare la probabilità di incidenti, in particolare tra i conducenti più anziani.

Non ci sono buoni motivi per usare lettere maiuscole e buoni motivi per non farlo.

Personalmente detesto usare maiuscole per le parole chiave SQL. Trovo più difficile da leggere e assurdo in questo giorno ed età.

Il linguaggio SQL è definito senza distinzione tra maiuscole e minuscole. Togli il dito dal tasto Maiusc!

Le maiuscole possono fornire un vantaggio nella visibilità delle parole chiave, ma puoi compensare l'evidenziazione e l'indentazione del codice.
Usiamo lettere minuscole perché l'editor di query e altri strumenti fanno miracoli nella modifica del codice t-sql e non vediamo la necessità di torturare il mignolo.

La scimmia vede, la scimmia fa per me. Pattern matching: se lo faccio nel modo in cui l'ho visto, la struttura delle clausole si allinea mentalmente più facilmente.

Le lettere maiuscole sono meno leggibili. Il contorno di tutte le parole ha la forma di scatole; non ci sono discendenti o ascendenti. FTW minuscolo!

Lo trovo più leggibile. Lo stesso per avere una nuova riga per l'inizio di ogni clausola e rientrare tra le clausole.

Prova un prodotto di formattazione (utilizzo SQL Prompt / SQL Refactor da Red Gate). Puoi impostare il modo in cui vuoi che funzioni la maiuscola e il tuo codice sarà sempre formattato in modo coerente. Riposa il tuo mignolo e lascia che il computer faccia il lavoro per te.

Uno dei motivi per continuare a usare le maiuscole è quando tu (o qualcun altro) stai visualizzando il codice in qualcosa come il blocco note, rende più facile la lettura. cioè puoi facilmente distinguere tra le "parole chiave" e i tablename, gli SP, gli udf ecc

Altro che conformità per motivi di conformità, n. Sebbene sia un argomento molto soggettivo, preferisco usare il caso misto per tutto l'SQL. L'SQL è molto più facile da leggere e nulla viene perso nei moderni IDE in cui le parole chiave sono comunque tutte codificate a colori.

Il completamento automatico / intellisense in Microsoft SQL Server Management Studio consente l'uso di maiuscole o minuscole per le parole riservate, ma le funzioni in maiuscolo chiamano MAX (), SUM ().

Anche così, il parser consente comunque di elaborare versioni minuscole di max () e sum ().

Ciò implica un'ambivalenza rispetto alla natura dell'esecuzione, e quindi è semplicemente una questione di preferenza personale.

Non mi piace tutto ciò che è scritto in maiuscolo (e odio scrivere ancora di più in maiuscolo), ma non riesco a convincermi ad andare contro la comunità. Come sempre Vim e i suoi pacchetti associati sono la soluzione a tanti problemi:

http://www.vim.org/scripts/script.php?script_id=305

Digita semplicemente come normale e capitalizzerà automaticamente le parole chiave durante la digitazione. Non ho usato tutti gli oscuri incantesimi SQL ma non mi ha ancora deluso.

Chiamo la maggior parte del mio codice mySQL da PHP, e faccio tutto il mio editing PHP all'interno di VIM (o suppongo che in questo caso, VIM ;-). Ora sono sicuro che ci sono plugin là fuori per evidenziare il codice mySQL all'interno di PHP, ma non l'ho trovato e non ho il tempo di andare a cercarlo. Pertanto, preferisco avere tutto in tutti i tappi. Lo trovo:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Mi aiuta a distinguere tra PHP e SQL molto meglio di questo:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Inoltre, per qualche motivo, odio mescolare tutti i tappi con la custodia di cammello, in questo modo:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

Questo IDmi irrita. Dovrebbe invece essere id? o iD?