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

128

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.

Hertanto Lie
la source
9
Essayez la touche CAPS LOCK. :)
MusiGenesis
7
Je dois toujours activer CAPS LOCK lorsque je veux écrire des mots-clés, puis désactiver lorsque je n'écris pas de mots-clés et activer à nouveau CAPS LOCK et ainsi de suite. C'est juste un problème.
Hertanto Lie
17
CAPS wha ... Oh, tu veux dire ma troisième touche Ctrl?
Dave Sherohman
2
IIRC, ce qui est amusant, c'est que si vous consultez les procédures sp_ ​​dans MSSQL, elles sont toutes en minuscules.
Benjol
1
@Benjol, pas tous mais certainement beaucoup comme sp_who. C'est une bonne idée d'essayer au moins d'être cohérent dans le même sproc, ce que Microsoft n'est pas dans beaucoup de "cas". Jeu de mots volontaire. LOL
Gordon Bell

Réponses:

107

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.

Blé Mitch
la source
6
+1 Je suppose que je n'étais pas le seul à utiliser tous les bas pour les mots clés.
dance2die
2
Je partirais avec l'hypothèse que cela remonte à l'époque où les éditeurs ne faisaient pas de coloration de code.
Benjol
10
Je suis assez sûr que cela remonte à l'époque où de nombreuses machines ne supportaient pas les caractères minuscules.
Nate CK
1
Je suppose que cela remonte aux jours avant les moniteurs couleur;)
walrii
150

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.

Gordon Bell
la source
8
C'est tellement une question de goût. D'après mon expérience, la quantité de cris n'est pas trop grande - je préfère les mots-clés en majuscules car ils sont beaucoup plus faciles à lire et les littéraux et les commentaires se démarquent.
Jonathan Leffler
93
+1 pour "JE N'AIME PAS MON SQL CRIANT AT ME"
dance2die
8
Je n'aime pas qu'un langage me crie dessus, mais cela ne pose pas la question de savoir si les majuscules sont une bonne idée en SQL.
bignose
85

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.

gros nez
la source
Je pense que la raison principale de cette question est assez bonne. Votre réponse est bien expliquée, mais semble toujours un peu basée sur l'opinion. Je n'ai pas l'impression que SQL ait autant de mots-clés. Quoi qu'il en soit, après les 50 mots clés les plus fréquents, à quelle fréquence en voyez-vous d'autres? Est-il toujours important de les montrer en majuscules? Comme ils sont peu fréquents, ils ont tendance à attirer l'attention de toute façon, n'est-ce pas? Bien sûr, ces sacrés «mots-clés non réservés» comme sql-server throwméritent un traitement spécial, mais les majuscules ne sont qu'une option parmi d'autres.
Frédéric
1
@ Frédéric, vous semblez soutenir que le lecteur n'a pas besoin de mots-clés moins connus pour être marqués comme mots-clés. Non, ces mots n'attirent pas l'attention précisément parce que l'on ne peut pas s'attendre à ce que le lecteur sache que ce sont des mots clés; c'est pourquoi ils doivent être distingués comme des mots clés comme les autres.
bignose
Peut-être que je suis trop ignorant sur SQL malgré mes nombreuses années de programmation avec SQL, mais jusqu'à présent, je crois avoir toujours repéré presque immédiatement des mots-clés que je ne connaissais pas, car ils aboutissaient à une construction SQL inhabituelle, du moins pour quelqu'un qui ne le sait pas les connaître.
Frédéric
33

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
davidtbernal
la source
1
Oui, c'est comme ça que je l'aime aussi.
David The Man
6
Le problème est ... Si vous capitalisez lors de l'exécution de commandes ad-hoc à une invite, vous serez toujours 1/2 aussi rapide que quelqu'un qui ne les capitalise pas si jamais vous devez exécuter des commandes ad-hoc en production quand il compte. J'écris donc tout en minuscules, puis «l'embellit» avant l'enregistrement quand quelqu'un se plaint de ne pas pouvoir le lire parce qu'il ne sait pas comment exécuter un surligneur de syntaxe. Et je ne sais pas pour vous, mais les 3 fois par an que je dois exécuter des commandes ad-hoc en vitesse de production importent vraiment, donc les 50% de jours de travail que j'ai pratiqués à écrire des requêtes de test en minuscules sont vraiment payants.
7
Et dans la base de données de mon entreprise (créée quelque part dans les années 90), tous les noms de tables, colonnes, index, procédures stockées, etc. sont tous en majuscules, c'est pourquoi nous optons pour des mots clés SQL en minuscules. ;)
Andreas
1
Wow 1/2 aussi vite. Je ne pense pas!
Iharob Al Asimi
33

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.

Lukas Eder
la source
Donc, pas une bonne raison aujourd'hui alors.
bignose
1
@BIGNOSE: NON, ABSOLUMENT PAS!
Lukas Eder
1
Je pense que c'est la meilleure réponse. Malheureusement, je déteste juste les minuscules dans les mots-clés SQL et je ne trouve pas de moyen d'aimer les minuscules, suis-je fou?
Iharob Al Asimi
@IharobAlAsimi OUI VOUS ÊTES FOU. POURQUOI ÉCRIVEZ-VOUS L'ANGLAIS EN CAS DE BAS, MAIS L'ANGLAIS STRUCTURÉ?
Lukas Eder
24

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.

AaronLS
la source
5
Nous ne parlons pas de lire un roman en majuscules; nous parlons d'une poignée de mots-clés qui ne sont qu'une partie du texte.
Casey
6
Vous manquez le point. Il ne s'agit pas du nombre de mots que nous lisons, mais de ce que notre cerveau a été entraîné à faire rapidement. Un panneau de signalisation par exemple n'est certainement pas un roman, mais ils sont arrivés à la même conclusion. Lorsque nous apprenons à lire, nous commençons à lire chaque lettre, mais finalement notre cerveau commence à reconnaître un mot comme un groupe de modèles. Il vaut mieux que ces modèles soient cohérents. N'oubliez pas que les lettres majuscules sont souvent un modèle différent des minuscules, et pas seulement une version plus grande.
AaronLS
1
Mais il y a très peu de mots-clés et ils apparaissent encore et encore; la reconnaissance devrait donc être tout aussi rapide pour quiconque utilise SQL depuis un certain temps.
Casey
3
Certes, ce n'est certainement pas quelque chose de dur et de rapide. Mais seuls quelques mots clés sont très courants. Il y a un grand ensemble qui ne le sont pas, et souvent les gens étendent cette pratique de la casse supérieure à des choses qui sont des fonctions intégrées mais pas nécessairement des mots-clés de langage syntaxique. En pratique, j'ajoute encore une petite poignée de mots-clés comme SELECT / WHERE / GROUP BY qui indiquent le début d'une section majeure d'une requête. Mais tous les autres mots - clés, tels que builtin fonctionne comme cast, rankje minuscules.
AaronLS
19

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!

Bohème
la source
3
Je pense que la prévalence des bonnes raisons présentées dans d'autres réponses va à l'encontre de votre affirmation «il n'y a aucune bonne raison d'utiliser des lettres majuscules».
bignose
7
@bignose Oh, il y a des raisons ... Je ne pense pas qu'elles soient bonnes. D'après mon expérience, plus le programmeur SQL est junior, plus il est susceptible d'utiliser des majuscules. A l'inverse, je n'ai jamais rencontré de codeur SQL compétent qui utilise des majuscules.
Bohème
3
Tout à fait d'accord. La prévalence d'autres «réponses» ne les rend pas correctes, elle les rend simplement prépondérantes. TOUTE LA CASSE SUPÉRIEURE EST UN HANGOVER DE LAQUELLE LES ORDINATEURS N'AIENT PAS DE CAS SUR LEURS CLAVIERS OU DANS LEURS REPRÉSENTATIONS DE PERSONNAGES. C'EST JUSTE SILLY AUJOURD'HUI.
Charles Bretana
Ouais et l'usure de votre touche CAPS LOCK ou des crampes aux doigts en maintenant les touches Shift enfoncées inutilement.
Gordon Bell
9
Je sens le raisonnement circulaire ici. Si la raison est présentée en faveur de la discrimination des mots-clés avec la casse, vous la rejetez comme une mauvaise raison. Si la raison est présentée par un codeur SQL mais n'est pas d'accord avec votre position, vous le rejetez comme n'étant pas un codeur SQL compétent . Je pense que sur cette base, nous pouvons rejeter cet argument comme étant invalide.
bignose
8

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.

Ovidiu Pacurar
la source
2
L'éditeur de requêtes et t-sql sont-ils les seuls endroits où quelqu'un lira votre code SQL? Comment le sais-tu?
bignose
8

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.

dkretz
la source
7

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!

Lance Fisher
la source
3
La raison que vous donnez soutient la position que les majuscules aident à distinguer les mots-clés du reste.
bignose
5
@bignose Si SQL se lit comme un langage humain, pourquoi avons-nous besoin de majuscules? Nous n'avons pas besoin de majuscules nos verbes OU prépositions EN langage humain. Imaginez SI CHAQUE phrase ressemblait à ceci. Je trouve cela moins lisible que l'écriture ordinaire. Les mots en majuscules dans ces deux phrases font que mon cerveau s'arrête et les prononce plus lentement que le reste de la phrase, ralentissant ma lecture et rendant le flux moins naturel.
Chris Middleton
1
Le langage humain pardonne très bien l'ambiguïté de la syntaxe. Les langages informatiques ne le sont pas, c'est pourquoi ces ambiguïtés doivent être minimisées. La syntaxe SQL n'aide pas avec cela, nous devons donc utiliser les outils disponibles; La syntaxe SQL n'a pas grand-chose, nous avons donc fait évoluer la convention de capitalisation des mots-clés.
bignose
5

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

Mark Bostleman
la source
2

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.

gfrizzle
la source
1
Ce conseil ignore les nombreux contextes dans lesquels SQL est lu. Ce n'est absolument pas pratique pour lire du code déjà écrit par quelqu'un d'autre; si un outil comme celui-ci est nécessaire juste pour rendre lisible un SQL mal formaté, c'est un argument en faveur d'une convention comme celle abordée par cette question.
bignose
mais cette approche est bonne si vous voulez des normes dans toute votre organisation. Si vous voulez des normes, l'opinion n'a pas d'importance
Trubs
2

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.

CPU_BUSY
la source
1

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.

Charles Bretana
la source
Comme beaucoup d'autres réponses ici ont présenté des raisons, je ne pense pas que votre réponse soit correcte: il y a des raisons «autres que la conformité pour la conformité».
bignose
... alors que sont-ils? Bien que toujours ouvert à de nouvelles informations, franchement, je n'en ai jamais eu connaissance.
Charles Bretana
J'ai déjà donné de nombreuses raisons , alors maintenant vous êtes au courant.
bignose
2
aucune de ces raisons n'est valable, ce sont des préférences personnelles. N'hésitez pas à faire selon vos préférences personnelles, mais ne définissez pas une préférence comme une règle ou une meilleure pratique.
Charles Bretana
1

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.

Facture
la source
4
Oui, et dans SSMS "Options -> Éditeur de texte -> Transact-SQL -> Intellisense", vous pouvez définir la valeur par défaut sur "Minuscules" si vous préférez.
Gordon Bell
0

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.

Ferdinand van Wyk
la source
-2

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?

vomir
la source
3
Non, non, non, camelCase est destiné aux noms de variables, pas aux noms de colonnes. Utilisez la casse appropriée pour les noms de colonne ... InsertDate, AlterDate, ...
Gordon Bell
1
Le standard SQL exige que les implémentations ignorent la casse dans les identificateurs (il les plie en majuscules). Votre code ne doit donc pas dépendre des différences de casse dans les identifiants, et la manière conventionnelle de le faire est de créer des identifiants all_lower_case.
bignose
3
@bignose Je ne suis pas un grand fan du trait de soulignement car il diminue le wpm
puk