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

La valeur par défaut semble être en majuscules, mais y a-t-il vraiment une raison d'utiliser des majuscules pour les mots-clés? J'ai commencé à utiliser des majuscules parce que j'essayais simplement 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 ensuite, je me suis senti mal pour mon bébé (5ème) doigt, qui doit toujours maintenir le Shiftbouton enfoncé, alors j'ai arrêté d'utiliser les majuscules. Une raison pour laquelle je devrais revenir aux majuscules?

Edit : Merci pour les réponses les gars. Je ne programmais pas encore à l'époque où COBOL était roi, donc je n'étais pas au courant de cela. Je m'en tiendrai désormais aux minuscules.

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

J'avais l'habitude de préférer toutes les majuscules, mais je me penche maintenant vers toutes les minuscules.

PERSONNELLEMENT, JE N'AIME PAS MON SQL CRIER CONTRE MOI. CELA ME RAPPELLE DE BASIC OU COBOL.

Je préfère donc mon T-SQL minuscule avec des noms d'objet de base de données MixedCase.

Il est beaucoup plus facile à lire et les littéraux et les commentaires ressortent.

SQL EST ANCIEN. LA CAISSE SUPÉRIEURE CRIE. Ça a l'air étrange et peut-être laid.

Bien que cela soit vraisemblablement vrai, aucun de ceux-ci n'aborde les raisons spécifiques au langage SQL pour lesquelles les mots-clés 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 des identifiants afin d'analyser mentalement la syntaxe.

La réponse directe à votre question est donc plutôt une réponse à «pourquoi le lecteur de code SQL profite- t-il autant des mots-clés en majuscules, alors que ce n'est pas aussi vrai pour la plupart des langages modernes?»:

• Se fier à garder les mots - clés dans sa tête est raisonnable pour de nombreux langages modernes, mais déraisonnable pour SQL ; il contient trop de mots clés et trop de variantes.

• Se fier aux signaux de ponctuation est raisonnable pour la plupart des langages 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 des surligneurs automatiques pour distinguer les mots-clés est raisonnable pour les langues 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.

Voici quelques-unes des raisons, spécifiques à SQL, pour lesquelles le lecteur de code SQL est mieux servi en normalisant les majuscules pour les mots - clés , et en utilisant uniquement des majuscules (c'est-à-dire des minuscules ou des 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 raisonnablement pas savoir qu'il s'agit de 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 partout 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 avec du 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 mis en évidence que par un qui connaît intimement votre variante SQL. Ainsi, le lecteur, même s'il utilise un surligneur, a 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'écrivain ne peut pas savoir à l'avance quand ce sera le cas - avoir besoin de l'aide du contenu de l'instruction SQL elle-même, pour savoir ce que l'écrivain entend comme mot-clé et ce qui est prévu comme identifiant. Le contenu SQL lui-même doit donc distinguer les mots-clés pour le lecteur , et l'utilisation de mots-clés en majuscules est le moyen conventionnel et utile de le faire.

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 à ceci:

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, car les mots-clés ressortent davantage. 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

IL ÉTAIT UN TEMPS O LA PLUPART DES PERSONNES N'AURAIENT PAS LA POSSIBILITÉ D'ENCODER QUELQUE CHOSE AU-DELÀ DES LETTRES MAJUSCULES MAJUSCULES PARCE QUE L'ENCODAGE PERTINENT (ASCII) N'ÉTAIT PAS ENCORE INVENTÉ. SEULEMENT SIX BITS ÉTAIENT DISPONIBLES . Tandis que SQL EST PLUS RÉCENT, LES LETTRES CASES INFÉRIEURES N'ONT PAS ENCORE ÉTÉ UNE PRATIQUE COMMUNE EN PROGRAMMATION.

NOTEZ QUE CERTAINES PERSONNES RÉCLAMENT QUE LA BASE DE DONNÉES AURA UN SENS D'URGENCE ET RÉALISERA VOS QUESTIONS PLUS RAPIDEMENT.

Moins de 10% des lettres du texte que nous lisons sont en majuscules. Par conséquent, nos cerveaux sont plus enclins à reconnaître les lettres minuscules que les majuscules. Des études ont montré que la lecture du texte en majuscules prend plus de temps. Voici 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 ne parlez que d'un ou deux mots, cela fait une différence.

C'est parce que SQL est un langage si ancien ( 1974 ) que lorsqu'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.

La recherche a prouvé que ALL CAPS est plus difficile à lire, à tel point que la Federal Highway Administration des États-Unis a rendu obligatoire l'utilisation de panneaux à casse mixte dans son manuel sur les dispositifs de contrôle de la circulation uniformes, qui stipule:

Le lettrage des noms de lieux, de rues et d'autoroutes sur les panneaux de guidage routier conventionnels doit être une combinaison de lettres minuscules avec des lettres majuscules initiales.

Le New York Post a également publié:

Des études ont montré qu'il est plus difficile de lire les panneaux en majuscules et que ces millisecondes supplémentaires passées à regarder loin de la route augmentent la probabilité d'accidents, en particulier chez les conducteurs plus âgés.

Il n'y a aucune bonne raison d'utiliser des lettres majuscules et de bonnes raisons de ne pas le faire.

Personnellement, je déteste utiliser des majuscules pour les mots clés SQL. Je trouve cela plus difficile à lire et absurde de nos jours.

Le langage SQL est défini comme étant insensible à la casse. Retirez votre doigt de cette touche Maj!

Les majuscules peuvent améliorer la visibilité des mots clés, mais vous pouvez compenser par la mise en évidence et l'indentation du code.
Nous utilisons des minuscules car l'éditeur de requêtes et d'autres outils font des merveilles dans l'édition du code t-sql, et nous ne voyons pas la nécessité de torturer le petit doigt.

Monkey voir, singe faire pour moi. Correspondance de motifs - si je le fais comme je l'ai vu, la structure des clauses s'aligne mentalement plus facilement.

Les majuscules sont moins lisibles. Le contour de tous les mots a la forme de cases; il n'y a ni descendants ni ascendeurs. FTW minuscule!

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

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 à votre place.

L'une des raisons pour lesquelles vous continuez à utiliser les majuscules est que lorsque vous (ou quelqu'un d'autre) affichez 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, SP, udf, etc.

Autre que la conformité pour des raisons de conformité, non. Bien que ce soit un sujet très subjectif, je préfère utiliser la casse 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 de toute façon codés par couleur.

L'intellisense / autocompletion dans Microsoft SQL Server Management Studio autorise les majuscules ou les minuscules pour les mots réservés, mais les appels de fonction en majuscules comme MAX (), SUM ().

Même ainsi, l'analyseur permet toujours de traiter les versions minuscules de max () et sum ().

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

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

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

Tapez simplement comme d'habitude et il mettra automatiquement en majuscule les mots-clé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 fait défaut.

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 de le chercher. Par conséquent, je préfère tout avoir en allcaps. Je trouve ça:

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 bien mieux que 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 );

Aussi, pour une raison quelconque, je déteste mélanger allcaps avec un étui camel, 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

Cela IDme dérange. Doit-il plutôt l'être id? ou iD?