Bonjour/Bonsoir,

J'aimerais quelques avis concernant des conventions de nommage à préférer, pour les noms se finissant par *name.

Quand je parles de nommage, c'est aussi bien pour les noms de dossiers/fichiers, les noms de variables, de classes, de méthodes, de paramètres de configuration, de champs en base de données, etc...

Quelques exemples pour préciser ma pensée :

class => classname
file => filename
host => hostname
user => username
path => pathname

La version courte est-elle considéré comme plus simple ou plus lisible, ou alors la version longue plus précise, correcte ?

De même, il y a d'autres équivalents parmi lesquels je ne sais choisir, à la différence que contrairement aux *name, c'est des noms raccourcis (alors que pour les *name les deux versions sont correctes) :

pass => password
dir => directory => folder
sys => system
lib => library
cfg => config => configuration
tmp => temp => temporary
app => application

Les versions courtes sont plus rapides à écrire, néanmoins c'est peut-être plus clair d'avoir les noms complets ?

Je doute qu'il y est réellement de "convention" précise à ce propos, d'autant plus que tout développeur connait ces noms, courts ou pas
Donc fais comme toi tu le préfères

Je met systématiquement des noms de variables complet. Cela dit, il y a des exceptions (comme tmp, app ou lib). Avoir des $cfg, ça me fait pas mal suer.

Je mets des noms courts dans certains cas et longs dans d'autres.

Par exemple, classname et class ne sont pas pareil pour moi.

Classname est le nom de la classe et Class la classe en elle-même. Il arrive parfois que faire la différence entre les deux peut-être nécessaire dans le code.

Pour la seconde série d'exemple, je pense que certains sont à proscrire parce qu'ils sont peu connu (cfg et tmp ...) alors que d'autres sont plus dans un usage courant (app, lib, pass, dir).

cfg et tmp peu connu?

@zed-laste: En général je préfères coller à la lettre à des conventions reconnues, mais je n'ai justement rien trouvé pour ces questions de nommage, du coup j'ai un peu l'impression de laisser les choses au hasard et je n'aimes pas ça.

Naturellement j'aurais tendance à utiliser les noms complets pour les noms du 2e exemple, même pour ceux qui sont extrêmement utilisés... après c'est peut-être un peu lourd d'avoir un dossier "configuration" alors que "cfg" est pas mal utilisé, ou "conf" ou encore "config", idem pour les autres noms en fait.

Je me disais quand même que quand on commence à utiliser des abréviations, même si elles sont bien connues, ça fait vite tache dès qu'on a un nom qui ne possède pas d'équivalent de 3-4 lettres :

- app
- app/classes
- app/cgf
- app/templates (ou app/tpl, mais peu utilisé)
- assets
- modules (ou mod, mais peu utilisé)
- sys

Du coup ça permettrait d'unifier le tout en utilisant les noms complets partout.

Pour les *name, c'est vrai que ça peut changer plus ou moins la signification selon le contexte... si j'ai une classe "File" je mettrais une instance dans une variable "file", et "filename" serait juste la chaîne avec le nom du fichier, mais dans d'autres cas où on a juste le nom on pourrait utiliser une variable "file" pour le nom sans problèmes, en revanche on perd une certaine uniformité dans le nommage.

D'un autre côté dans certains cas ça fait un peu lourd de rajouter le *name, si je fais un upload d'images, en base de données je pourrais avoir "id;title;filename", mais "file" suffirait dans ce contexte... et d'ailleurs pourquoi pas "path", ou "pathname" ?

Dans la doc (ou devrais-je dire documentation) de PHP, j'ai l'impression qu'ils utilisent toujours la version longue, et ça me semble plutôt correct à utiliser, bien que ce soit plus lourd quand le contexte ne nécessite pas de précision, je crois que je vais partir là-dessus.

Se pose alors une autre question pour lesquelles j'ai du mal à trouver une logique dans le nommage.

Dans la bibliothèque standard de PHP :

unlink($filename) // un fichier et pas autre chose
rmdir($dirname) // un dossier et pas autre chose
chmod|chown($filename) // un fichier ou un dossier
mkdir($pathname) // un dossier qui n'existe pas encore

Dans le module "fs" de node.js les fonctions équivalentes prennent toutes "path" en paramètre, indépendamment d'un dossier ou fichier...

Filename et pathname sont bien dans le dictionnaire anglo-saxon (également corrects sous la forme "file name" et "path name" ), mais dirname n'en fait pas partie.

Sauf que dans l'histoire, il me semble que d'après le système de fichier UNIX un "nom de fichier" peut aussi bien représenter un fichier ou un répertoire... d'un point de vue sémantique "filename" et "pathname" deviendraient alors équivalents ?

Mais y a-t-il une différence entre "path" et "pathname" ? Un chemin représente naturellement une chaîne de caractère localisant un fichier ou un dossier, pas besoin de dire qu'il s'agit d'un nom de chemin, je dirais même que ça n'a pas de sens.

Donc on pourrait se mettre à tout appeler "path", mais lorsqu'un a besoin de plus de précision, à savoir si l'on cible un dossier, un fichier, mais pas les deux... "filename" est correct ("fileName" l'est aussi et ça me perturbe), mais dirname n'est pas anglais. Serais-ce donc plus judicieux pour le côté sémantique d'appeler des variables "filePath", et "directoryPath" ?

Pour moi :

dir = directory <=> répertoire

file <=> filename <=> fichier
filename ~<=> basename <=> nom du fichier
(on peut avoir un ressenti différent suivant le contexte)

et grosso modo :

path <=> file <=> filename <=> directory + (basename | filename)