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

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.

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.

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

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.

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.

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.

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.

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.

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!

Je le trouve plus lisible. Idem pour avoir une nouvelle ligne pour le début de chaque clause et l'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 pour vous.

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.

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.

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.

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é.

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?