Cas Pascal under_scores, camelCase et PascalCase – Les trois conventions de nommage que tout programmeur devrait connaître

Les différents tokens de votre code (variables, classes, fonctions, espaces de noms, etc.) peuvent être nommés en utilisant l’un de ces trois styles, au sens large :

  1. Camel Case (ex : someVar, someClass, somePackage.xyz).
  2. Pascal Case (ex : SomeVar, SomeClass, SomePackage.xyz).
  3. Underscores (ex : quelque_var, quelque_class, quelque_package.xyz).

En casse camel, les noms commencent par une minuscule mais chaque mot propre du nom prend une majuscule, de même que les acronymes. Par exemple, les tokens couramment utilisés dans de nombreux langages tels que toString, checkValidity, lineHeight, timestampToLocalDateTime, etc. sont tous des exemples de casing camel.

La mise en forme en castillon est similaire à la mise en forme en camel sauf que la première lettre commence également par une majuscule (SomeClass au lieu de someClass).

Dans la mise en forme en soulignement, tout est en minuscule (même les acronymes) et les mots sont séparés par des traits de soulignement (some_class, some_func, some_var, etc). Cette convention est aussi populairement connue sous le nom de snake case.

L’idée générale est que vous pouvez utiliser n’importe quelle convention dans votre projet tant que vous êtes cohérent quant à son utilisation partout. Mais lorsque vous codez pour un grand projet ou une équipe, vous devez vous conformer à la norme de ce qui y est utilisé. D’où l’utilité de connaître les conventions typiques des différents langages de programmation.

La pratique générale pour un langage de style C comme Java ou JS est d’utiliser la camelCase pour toutes les variables et les membres des objets (propriétés & méthodes), et la PascalCase pour les noms de classe et les constructeurs. Les espaces de noms (ou Packages dans le monde Java) sont généralement en camelCase.

Mais certains langages font exception à cette règle. C#, par exemple, utilise la PascalCase pour les espaces de noms et même les méthodes publiques. Par conséquent, la fonction principale (ou point d’entrée) est toujours static void main() en java mais static void Main() en C# (Notez la majuscule du mot « Main »).

Certains langages qui ne dérivent pas leur syntaxe du C (comme Python & Ruby) utilisent des underscores pour presque tout sauf les noms de classe. D’où son toujours sys.base_prefix au lieu de sys.basePrefixdatetime au lieu de DateTimestr.splitlines() au lieu de str.splitLines() en python.

Dans le cas de la bibliothèque standard de python, j’ai remarqué que même les classes utilisent parfois des underscores ce qui est une incohérence. Par exemple, datetime.datetime est une classe et csv.excel_tab l’est aussi. Les frameworks et bibliothèques populaires cependant (comme django et flask) utilisent la casse camel pour les classes.

Une incohérence similaire se trouve en PHP. Le langage évolue de l’underscore à la casse camel ces dernières années mais certains vieux tokens hantent encore ce langage. Par ex, mysqli::set_local_infile_default vs PDOStatement::debugDumpParams.

Donc, en fin de compte, cela revient à votre propre préférence lorsque vous démarrez un projet. Mais il est utile de savoir quelles sont les conventions habituellement suivies dans les projets open source populaires dans la langue de votre préférence.

Mise à jour

Il existe également un quatrième cas, comme l’a souligné @ovais, à savoir le cas kebab. C’est très similaire au casing underline sauf que les soulignements sont remplacés par des tirets (hyphens). Ainsi, some_func devient some-func, ce qui est évidemment interdit car le tiret n’est pas utilisé pour nommer les jetons, car il est déjà intégré pour l’opérateur moins dans la plupart des langages de programmation. Là où la casse kebab est utilisée le plus fréquemment, c’est pour créer des classes dans vos feuilles de style css ! Des noms comme main-divmain-navbar et article-footer sont couramment utilisés par les développeurs web lors de l’écriture de leur HTML/CSS. Cette convention est essentiellement le cas du kebab.

Mise à jour

Comme le dit @patrykrudnicki, les constantes sont traitées différemment. D’après mon expérience, le soulignement complet (SOME_CONST) est une convention populaire pour les constantes dans de nombreux langages, notamment Java, PHP et Python.

Mise à jour

Pour résumer, il s’agit de la convention typique ou généralement suivie dans les langages de programmation open source les plus utilisés :

.

.

.

Token python Java/JS PHP
variable sous_score camelCase mix (évolution vers camelCase)
fonction sous_score() camelCase() mix (évolution vers camelCase())
constant UNDER_SCORE UNDER_SCORE UNDER_SCORE
class PascalCase PascalCase mix (évolution vers PascalCase)
namespace under_score camelCase mix (évolution vers PascalCase)

Certains liens utiles :

  1. https://softwareengineering.stackexchange.com/questions/196416/whats-the-dominant-naming-convention-for-variables-in-php-camelcase-or-undersc
  2. https://stackoverflow.com/questions/149491/pascal-casing-or-camel-casing-for-c-sharp-code
  3. https://www.c-sharpcorner.com/forums/when-to-use-camel-case-and-pascal-case-c-sharp
  4. https://softwareengineering.stackexchange.com/questions/53498/what-is-the-philosophy-reasoning-behind-cs-pascal-casing-method-names

.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *