Y a-t-il une bonne raison d'utiliser des majuscules pour les mots-clés SQL? [fermé]

Par défaut semble être en majuscules, mais est-il vraiment aucune raison d'utiliser des majuscules pour les mots clés? J'ai commencé à utiliser des majuscules parce que j'essayais juste de faire correspondre ce que SQL Server me donne chaque fois que j'essayais de créer quelque chose, comme une nouvelle procédure stockée. Mais alors, je me sentais mal pour mon bébé (5ème) doigt, qui doit toujours maintenir le bouton Shift , alors j'ai arrêté d'utiliser des majuscules. Une raison pour laquelle je devrais retourner en majuscules?

Edit: Merci pour l' réponses les gars. Je ne programmais pas encore à l'époque où COBOL {[8] } était roi, donc je n'étais pas au courant de cela. Je vais rester avec les minuscules à partir de Maintenant.

101
demandé sur Filipp W. 2008-11-15 05:22:44

17 réponses

C'est juste une question de style, probablement à l'époque où les éditeurs ne faisaient pas de coloration de code.

Je préférais toutes les majuscules, mais je me penche maintenant vers toutes les majuscules.

83
répondu Mitch Wheat 2008-11-15 02:25:24

PERSONNELLEMENT, JE N'AIME PAS QUE MON SQL ME CRIE DESSUS. CELA ME RAPPELLE BASIC OU COBOL.

Donc je préfère mes minuscules T-SQL avec des noms D'objets de base de données MixedCase.

Il est beaucoup plus facile à lire, et les littéraux et les commentaires se distinguent.

121
répondu Gordon Bell 2008-11-15 05:13:42

SQL EST ANCIEN. MAJUSCULES EST CRIANT. IL SEMBLE ÉTRANGE ET PEUT-ÊTRE LAID.

Bien que cela soit sans doute vrai, aucun de ceux-ci n'aborde les raisons spéciales au langage SQL pour lesquelles les mots-clés en majuscules sont une bonne convention.

Contrairement à de nombreux langages plus récents, SQL a un grand nombre de mots-clés et repose sur la capacité du lecteur àdistinguer les mots-clés par rapport aux identificateurs afin d'analyser mentalement la syntaxe.

La réponse directe à votre question, alors, est plus une réponse à " pourquoi le lecteur de code SQL bénéficie-t-il tant de des mots-clés majuscules, alors que ce n'est pas aussi vrai pour la plupart des langages modernes?":

  • Compter sur le maintien des mots-clés dans sa tête est raisonnable pour de nombreux langages modernes, mais déraisonnable pour SQL ; il a trop de mots-clés, et trop de variantes.

  • De s'appuyer sur ponctuation indices est raisonnable pour la plupart des langues modernes, mais déraisonnable pour SQL ; il en a trop peu, en fonction de l'ordre précis des mots-clés pour indiquer la syntaxe.

  • S'appuyer sur surligneurs automatiques pour distinguer les mots-clés est raisonnable pour les langages modernes dans les cas habituels, mais ignore la réalité de ce que les surligneurs peuvent réaliser pour SQL . La plupart ne couvrent pas tous les mots-clés de toutes les variantes de SQL, et quoi qu'il en soit, SQL est fréquemment et régulièrement lu dans des contextes où un surligneur n'aidera pas.

Ces sont quelques-unes des raisons, spécifiques à SQL, que le lecteur de code SQL est mieux servi par standardiser en majuscules pour les mots-clés , et seulement en utilisant Non-majuscules (c'est-à-dire inférieures ou mixtes) pour les identificateurs.

La mise en évidence peut parfois aider. Mais seulement si le surligneur sait que vous avez SQL; et nous avons très souvent SQL dans un contexte où l'éditeur / formateur ne peut pas raisonnablement savoir qu'il a affaire à SQL. Les exemples incluent les requêtes en ligne, la documentation du programmeur et les chaînes de texte dans le code d'une autre langue. La même chose n'est pas vraie aussi souvent pour des langages comme Python ou C++; oui, leur code apparaît parfois à ces endroits, mais ce n'est pas systématiquement fait comme c'est le cas avec le code SQL.

En outre, le lecteur utilisera généralement un surligneur qui ne connaît qu'un sous-ensemble des mots-clés utilisés par votre implémentation SQL spécifique. La plupart des mots-clés les moins courants ne seront pas mis en évidence, sauf par un qui connaît intimement votre variante SQL. De sorte que le lecteur, même s'ils utilisent un surligneur, ils ont toujours besoin d'un moyen plus direct de distinguer les mots-clés dans toute instruction SQL modérément complexe.

Ainsi, le lecteur aura souvent-et l'auteur ne peut pas savoir à l'avance quand cela sera – besoin d'aide du contenu de L'instruction SQL elle-même, pour savoir ce qui est prévu par l'auteur comme mot-clé et ce qui est prévu comme identifiant. Ainsi, le contenu SQL lui-même doit distinguer les mots-clés pour le lecteur , et en utilisant les mots-clés majuscules sont le moyen conventionnel et utile de le faire.

61
répondu bignose 2017-06-16 02:04:31

Les exemples de Gordon Bell ne sont pas tout à fait corrects; généralement, seuls les mots-clés sont mis en surbrillance, pas la requête entière. Son deuxième exemple ressemblerait à:

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

Je trouve cela beaucoup plus facile à lire, puisque les mots-clés ressortent plus. Même avec la coloration syntaxique, je trouve l'exemple non capitalisé beaucoup plus difficile à lire.

Dans mon entreprise, nous allons un peu plus loin avec notre formatage 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
30
répondu davidtbernal 2014-10-17 16:09:57

IL FUT UN TEMPS OÙ LA PLUPART DES GENS N'AVAIENT PAS LA POSSIBILITÉ D'ENCODER QUOI QUE CE SOIT AU-DELÀ DES LETTRES MAJUSCULES PARCE QUE L'ENCODAGE PERTINENT (ASCII) N'ÉTAIT PAS ENCORE INVENTÉ. SEULS SIX BITS ÉTAIENT DISPONIBLES . BIEN QUE SQL SOIT PLUS RÉCENT, LES LETTRES MINUSCULES N'ÉTAIENT PAS ENCORE UNE PRATIQUE COURANTE EN PROGRAMMATION.

NOTEZ QUE CERTAINES PERSONNES AFFIRMENT QUE LA BASE DE DONNÉES AURA UN SENTIMENT D'URGENCE ET EXÉCUTERA VOS REQUÊTES PLUS RAPIDEMENT.

23
répondu Lukas Eder 2018-03-12 09:36:41

Moins de 10% des lettres dans le texte, nous lisons sont en majuscules. Par conséquent, nos cerveaux sont plus désireux de reconnaître les lettres minuscules que les majuscules. Des études ont montré qu'il faut plus de temps pour lire le texte en majuscules. Voici juste un exemple:

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

L'exemple ci-dessus, je pense, souligne que même lorsque vous parlez d'un ou deux mots, Cela fait une différence.

19
répondu AaronLS 2018-09-27 15:52:55

C'est parce que SQL est un langage si ancien(1974) que quand il a été conçu, la plupart des claviers n'avaient pas de lettres minuscules! La documentation linguistique reflétait simplement la technologie de l'époque.

Il n'y a pas de bonne raison d'utiliser des lettres majuscules. Personnellement, je déteste utiliser des majuscules pour les mots-clés SQL. Il est plus difficile à lire et est ridicule de nos jours et inutile; le langage SQL est défini pour être insensible à la casse.

16
répondu Bohemian 2012-08-14 03:02:31

Majuscules peut fournir un gain dans la visibilité des mots clés, mais vous pouvez compenser avec le code en surbrillance et l'indentation.
Nous utilisons des minuscules parce que l'éditeur de requêtes et d'autres outils font des merveilles dans l'édition de code T-sql, et nous ne voyons pas besoin de torturer le petit doigt.

8
répondu Ovidiu Pacurar 2008-11-15 02:29:30

Singe voir, singe faire pour moi. Pattern matching-si je le fais comme je l'ai vu, la structure des clauses s'aligne mentalement plus facilement.

8
répondu dkretz 2008-11-15 02:45:44

Majuscule est moins lisible. Le contour de tous les mots sont en forme de boîtes; il n'y a pas de descendeurs ou d'ascendeurs. Minuscule FTW!

7
répondu Lance Fisher 2008-12-09 07:11:15

Je le trouve plus lisible. Idem pour avoir une nouvelle ligne pour le début de chaque clause et l'indentation entre les clauses.

5
répondu Mark Bostleman 2008-11-15 02:52:15

Essayez un produit de formatage (j'utilise SQL Prompt / SQL Refactor de Red Gate). Vous pouvez définir comment vous voulez que la capitalisation fonctionne, et votre code sera toujours formaté de manière cohérente. Reposez votre petit doigt et laissez l'ordinateur faire le travail pour vous.

2
répondu gfrizzle 2008-11-15 03:21:45

L'une des raisons pour continuer à utiliser la capitalisation est que lorsque vous(ou quelqu'un d'autre) visualisez du code dans quelque chose comme le bloc-notes, cela facilite la lecture. c'est-à-dire que vous pouvez facilement différencier les "mots-clés" et les noms de table, les SP, les udf, etc.

2
répondu CPU_BUSY 2008-11-15 04:14:12

Autre que la conformité pour des raisons de conformité, Non. Bien que ce soit un sujet très subjectif, je préfère utiliser un cas mixte pour tout SQL. Le SQL est beaucoup plus facile à lire, et rien n'est perdu dans les IDE modernes où les mots-clés sont tous codés par couleur de toute façon.

1
répondu Charles Bretana 2008-11-15 04:04:23

L'IntelliSense / autocomplétion dans Microsoft SQL Server Management Studio permet des majuscules ou des minuscules pour les mots réservés, mais des appels de fonction majuscules comme MAX (), SUM ().

Malgré cela, l'analyseur permet toujours de traiter les versions minuscules de max() et sum ().

Cela implique une ambivalence par rapport à la nature de l'exécution, et est donc simplement une question de préférence personnelle.

1
répondu Bill 2011-11-22 21:58:52

Je n'aime pas tout ce qui est écrit en majuscules (et je déteste encore plus taper toutes les majuscules), mais je n'ai pas pu me convaincre d'aller à l'encontre de la communauté. Comme d'habitude, Vim et ses paquets associés sont la solution à tant de problèmes:

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

Tapez simplement comme normal et les mots-clés seront automatiquement capitalisés au fur et à mesure que vous tapez. Je n'ai pas utilisé toutes les incantations SQL obscures mais cela ne m'a pas encore échoué.

0
répondu Ferdinand van Wyk 2015-08-30 23:30:55

J'appelle la plupart de mon code mySQL depuis PHP, et je fais toute mon édition PHP dans vim (ou je suppose dans ce cas, VIM ; -). Maintenant, je suis sûr qu'il existe des plugins pour mettre en évidence le code mySQL dans PHP, mais je ne l'ai pas trouvé, et je n'ai pas le temps d'aller le chercher. Donc, je préfère avoir tout dans allcaps. Je trouve ceci:

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 );

M'aide à faire la distinction entre PHP et SQL beaucoup mieux que cela:

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 );

Aussi, pour une raison quelconque, je déteste mélange allcaps avec camel case, comme ceci:

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

Ça m'énerve. Devrait-il plutôt être id? ou iD?

-2
répondu puk 2012-04-23 11:08:55