Nom de fichier? Nom du chemin? Nom de base? Norme de dénomination pour les morceaux d'un chemin

228

Je continue à me mettre en nœuds lorsque je manipule des chemins et des noms de fichiers, car je n'ai pas de système de nommage commun que j'utilise.

Je dois trouver une norme de dénomination et la respecter, et je voudrais être clair et cohérent avec les autres, donc je m'ouvre pour apprendre les réponses canoniques.

Considérez ce problème de jouet: (exemple Windows, mais j'espère que la réponse devrait être indépendante de la plateforme)

Vous avez reçu le nom complet d'un dossier: C: \ users \ OddThinking \ Documents \ My Source. Vous voulez parcourir les dossiers en dessous et compiler tous les fichiers .src en .obj.

À un moment donné, vous regardez la chaîne suivante.

C:\users\OddThinking\Documents\My Source\Widget\foo.src

Alors, quels noms d'identifiants utiliseriez-vous pour les pièces?

A) foo
B) foo.src
C) src
D) .src
E) C:\users\OddThinking\Documents\My Source\ - i.e. the top of the tree.
F) Widget\foo.src - i.e. the path from the top of the tree to the leaf.
G) Widget - i.e. one node of the tree.
H) C:\users\OddThinking\Documents\My Source\Widget\ - i.e. the name of the folder
I) C:\users\OddThinking\Documents\My Source\Widget\foo.src

Permettez-moi de donner quelques réponses, pour commencer.

A) nom de base?

B) nom de fichier? Ou est-ce un nom de fichier? La différence est importante lors du choix des noms d'identifiants, et je ne suis jamais cohérent ici.

C) Extension

D) Extension. Attendez, c'est ce que j'ai appelé C. Dois-je éviter de stocker le point, et simplement le mettre en cas de besoin? Et s'il n'y a pas de point sur un fichier particulier?

H) nom du chemin? Ou attendez, est-ce juste le chemin?

I) nom de fichier. Attendez, c'est ce que j'ai appelé C. Path. Attendez, c'est ce que j'ai appelé H. Peut-être que H devrait être le nom du dossier. Mais "dossier" n'est-il pas un terme propre à Windows?

Pensée étrange
la source
Mike Pope, rédacteur technique chez Microsoft, souligne sur son blog que si le guide de style Microsoft s'en tient systématiquement à deux mots: nom de fichier, nom de dossier, nom de volume, le Apple Style Guide les rejoint parfois: nom de fichier, chemin d'accès, nom de volume .
Oddthinking
A) ne devrait certainement pas être appelé nom de base car le nom de base est déjà utilisé dans de nombreux endroits pour désigner le dernier élément d'un chemin (pour un fichier, ce serait le nom de fichier sans dirpath). Certains endroits appellent le nom de fichier sans extension le stem.
wisbucky
De plus, pour les fichiers à plusieurs périodes (par exemple, foo.src.txt), existe-t-il un moyen standard d'identifier (et de nommer) l'extension / les extensions?
user117529

Réponses:

178

Je pense que votre recherche d'une convention de dénomination "standard" sera vaine. Voici mes propositions, basées sur des programmes existants et bien connus:

A) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src

Vim l'appelle racine de fichier (: aide modificateurs de nom de fichier)

B) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

nom de fichier ou nom de base

C) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo. src (sans point)

extension de fichier / nom

D) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src (avec point)

extension de fichier également . Stockez simplement sans le point, s'il n'y a pas de point sur un fichier, il n'a pas d'extension

E) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

sommet de l'arborescence
Pas de convention, git l'appelle répertoire de base

F) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin du haut de l'arbre vers le
chemin relatif de la feuille

G) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

un nœud de l'arbre
sans convention, peut-être un simple répertoire

H) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

nom du répertoire

I) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin complet / absolu

blinry
la source
8
Cela devient hors sujet, mais soyez prudent avec le stockage de l'extension séparé du point. Vous devez gérer les noms de fichiers "foo", "foo". et "foo.txt" (et même "foo.txt.bak".)
Oddthinking
1
salut les gars, excellent exemple. Il serait plus facile à lire si vous mettez la réponse à côté de la question, au lieu d'utiliser des références qui obligent à faire défiler vers le haut. Je fais d'ailleurs un montage pour améliorer ça. Grettings
Victor
3
Victor, puisque votre montage a été rejeté (les gars de wtf, c'est une très bonne amélioration!) Je viens de le faire moi-même :-)
blinry
1
Pour 1.(nom de fichier uniquement sans extension), j'ai décidé d'y aller File Titleil y a longtemps en raison de l'absence d'une convention claire ou du moins d'un consensus mondial.
polyvertex
1
Pour A(nom de fichier sans extension), vous pouvez utiliser stem. Références: doc.rust-lang.org/std/path/struct.Path.html#method.file_stem , llvm.org/docs/doxygen/html/… , boost.org/doc/libs/1_60_0/libs/filesystem/ doc /…
wisbucky
36

Bonne question tout d'abord, mon +1. Cette chose m'a dérangé quand j'ai dû créer une multitude de fonctions dans la classe Utility une fois. GetFileName? ou GetFullName? GetApplicationPath signifie le chemin complet ou le nom du répertoire? etc. Je viens de l'arrière-plan .NET, donc je pense que je peux ajouter un peu plus à une excellente réponse par @blinry.

Résumé: (en italique est ce que je n'utiliserais pas en tant que programmeur)

  1. Path : Path spécifie un emplacement unique dans le système de fichiers (à moins que son chemin relatif). Le nom du chemin est moins souvent utilisé, mais je m'en tiendrai au chemin - il explique à peu près ce que c'est. Le chemin peut pointer vers un fichier ou un dossier ou même rien (C: \). Le chemin peut être:

    1. Chemin relatif : My Source\Widget\est le chemin relatif ainsi que Widget\foo.src. Explicite.
    2. Chemin absolu ou chemin complet : il s'agit du chemin complet qui pointe vers la cible. J'ai tendance à utiliser ce dernier plus souvent. C:\users\OddThinking\Documents\My Source\Widget\foo.srcest donc chemin complet. Voir à la fin ce que j'appelle le chemin complet qui pointe vers un fichier et qui se termine comme un répertoire.

    La page wiki et la dénomination .NET pour le chemin d' accès sont cohérentes.

  2. Chemin racine ou répertoire racine : l'ancien est la convention .NET tandis que le second est plus entendu dans les cercles UNIX. Bien que j'aime les deux, j'ai tendance à utiliser le premier plus. Dans Windows, contrairement à UNIX, il existe de nombreux chemins racine différents, un pour chaque partition. Les systèmes Unix ont un répertoire racine qui contient des informations sur d'autres répertoires et fichiers. Par exemple. C:\est le chemin racine.

  3. Dossier ou Nom du dossier : Widget, OddThinkingetc dans votre cas. Cela pourrait être une convention Windows uniquement (en fait, c'est ma propre pensée étrange :)), néanmoins je m'oppose fortement à la réponse de Blinry "Directory". Bien que pour un répertoire utilisateur normal, cela signifie la même chose qu'un dossier (comme les sous-dossiers, les sous-répertoires), je pense que d'un point de vue technique, le "répertoire" devrait ressembler à une adresse qualifiée pour la cible et non la cible elle-même. Plus ci-dessous.

    1. Sous-dossiers : en ce qui concerne users OddThinkinget Documentssont des sous-dossiers.
    2. Sous répertoires : En ce qui concerne users OddThinking\, OddThinking\Documents\et OddThinking\Documents\My Source\Widget\sont des sous - répertoires. Mais nous n'avons pas souvent besoin de nous en préoccuper, n'est-ce pas?
    3. Dossier enfant : en ce qui concerne users OddThinkingun dossier enfant (ainsi qu'un sous-dossier)
    4. Dossier parent : car OddThinking usersc'est son dossier parent (juste en mentionnant différentes terminologies, ce n'est pas grave).
  4. Répertoire ou nom de répertoire : le premier à utiliser généralement dans la vie réelle, le second à être en code. Il s'agit du chemin d' accès complet (ou simplement du chemin d'accès complet ) jusqu'au dossier parent de la cible . Dans votre cas, C:\users\OddThinking\Documents\My Source\Widget(Oui, un répertoire n'est jamais destiné à pointer vers un fichier). J'utilise le nom du répertoire dans mon code car le répertoire est une classe en .NET et le nom du répertoire est ce que la bibliothèque elle-même appelle. Son tout à fait cohérent avec dirname utilisé dans les systèmes UNIX.

  5. Nom de fichier ou nom de base : nom du fichier avec extension. Dans votre cas: foo.src. Je dirais que pour une utilisation non technique, je préfère le nom de fichier (c'est ce que cela signifie pour un utilisateur final) mais à des fins techniques, je m'en tiendrai strictement au nom de base . Le nom de fichier est souvent utilisé par MS, mais je suis surpris de voir à quel point ils ne sont pas cohérents non seulement dans la documentation, mais même dans la bibliothèque . Le nom de fichier peut signifier le nom de base ou le chemin complet du fichier. Je préfère donc le nom de base, c'est ce que je les appelle en code. Cette page sur le wiki indique également que le nom de fichier peut signifier soit le chemin complet, soit le nom de base. Étonnamment, même dans .NET, je peux trouver le nom de base d'utilisation pour désigner le nom racine du fichier.

  6. Extension ou nom de fichier d' extension ou fichier d' extension : Je aime le dernier. Tout se réfère à la même chose mais qu'est-ce que c'est encore une question de débat! Wiki dit que c'est srcà l'époque, je me souviens avoir lu que de nombreuses langues l'interprètent comme .src. Notez le point. Donc, encore une fois, je pense que pour les utilisations occasionnelles, peu importe ce que c'est, mais en tant que programmeur, je considère toujours l'extension comme .src.

    Ok, j'aurais peut-être essayé de récupérer certaines utilisations standard, mais voici deux de mes conventions que je suis. Et il s'agit de chemins complets.

    1. J'appelle généralement un chemin complet qui pointe vers un fichier comme chemin de fichier . Pour moi, le chemin du fichier est clair, il me dit de quoi il s'agit. Bien qu'avec le nom de fichier, je le trouve comme nom de fichier, dans mon code, je l'appelle nom de fichier . Il est également cohérent avec " nom de répertoire ". Du côté technique, le nom fait référence au nom complet! Frustrant .NET utilise le terme nom de fichier (donc j'ai mon cas ici) et parfois chemin de fichier pour cela.

    2. J'appelle un chemin complet qui se termine comme un répertoire un répertoire. En fait, on peut appeler n'importe quel morceau d'adresse qui ne pointe pas vers un fichier un répertoire. Il en C:\users\OddThinking\Documents\My Source\va de même pour un répertoire, C:\users\OddThinking\un répertoire ou même OddThinking\Documents\My Source\(mieux vaut l'appeler sous-répertoire ou encore meilleur chemin relatif - tout cela dépend du contexte avec lequel vous l'utilisez). Bien au-dessus, j'ai mentionné quelque chose de différent à propos du répertoire qui est le nom du répertoire. Voici mon point de vue: j'obtiendrai un nouveau chemin pour éviter toute confusion. Qu'est-ce que c'est D:\Fruit\Apple\Pip\? Un annuaire. Mais si la question est de savoir quel est le répertoire ou encore mieux le nom du répertoire D:\Fruit\Apple\Pip\, la réponse est D:\Fruit\Apple\. J'espère que c'est clair.

    Je dirais qu'il vaut mieux ne pas se soucier des deux derniers termes car c'est ce qui crée le plus de confusion (pour moi personnellement). Utilisez simplement le terme chemin complet !

Pour vous répondre:

  1. par rapport au chemin que vous avez tracé

    A) Aucune idée. Quoi qu'il en soit, je n'ai jamais eu besoin de l'avoir seul.

    B) nom de base

    C) Je l'appellerais simplement extension de fichier pour le moment, je suis moins inquiet car je n'ai jamais eu besoin de cela seul pour être nommé dans mon code.

    D) extension de fichier sûrement.

    E) Je ne pense pas que ce soit une exigence générale. Aucune idée. Dans .NET, le répertoire de base est identique au nom du répertoire.

    F) chemin relatif

    G) dossier (dossier parent du nom de base foo.src)

    H) nom du répertoire

    I) chemin complet (ou même nom de fichier)

  2. en général (désolé d'être un peu bavard, juste pour ramener le point à la maison) mais en supposant qu'il foo.srcs'agit bien d'un fichier

    A) NA

    B) nom de base

    C) NA

    D) extension

    E) répertoire ou simplement chemin

    F) chemin relatif

    G) NA

    H) répertoire ou simplement chemin

    I) chemin complet (ou même nom de fichier)

Conduite plus loin avec un exemple de mon côté:

  1. Considérez le chemin C:\Documents and Settings\All Users\Application Data\s.sql.

    1. C:\Documents and Settings\All Users\Application Data\s.sql est le chemin complet (qui est un nom de fichier)
    2. C:\Documents and Settings\All Users\Application Data\ est le nom du répertoire.
  2. Considérez maintenant le chemin C:\Documents and Settings\All Users\Application Data

    1. C:\Documents and Settings\All Users\Application Data est le chemin complet (qui se trouve être un répertoire)
    2. C:\Documents and Settings\All Users est le nom du répertoire.

Deux conseils à moi:

  1. Je respecte cette règle empirique selon laquelle, lorsqu'il s'agit d'adresser une adresse complète, quel que soit son type, je l'appelle presque toujours "chemin complet". Cela élimine non seulement l'utilisation de deux terminologies pour le chemin de fichier et le chemin de dossier, mais évite également la confusion potentielle si vous allez nommer celui du fichier comme nom de fichier (qui pour la plupart des utilisateurs se traduit immédiatement par nom de base). Mais oui, si vous devez être précis sur le type de chemin, il vaut mieux nommer alors le nom de fichier ou le répertoire au lieu de "chemin" plus générique.

  2. Quoi que ce soit, vous auriez votre propre idée en tête, soyez cohérent avec elle tout au long. Ayez un consensus parmi les membres de l'équipe que cela signifie ceci et non cela.

Maintenant que juste du cercle j'ai une certaine pratique. Une nouvelle marque de termes serait celle qui est utilisée sur OS X et les machines Android. Et tout cela ne concerne que les chemins physiques dans le système de fichiers. Un tout nouvel ensemble de terminologies apparaîtrait dans le cas des adresses Web. Je m'attends à ce que quelqu'un comble le vide dans ce même fil :) Je serais heureux d'entendre la convention avec laquelle vous avez avancé ..

nawfal
la source
Depuis longtemps, j'utilise le mot "chemin d'accès" pour désigner le chemin absolu complet, y compris le nom de fichier complet. Votre réponse, d'autres ici et des ressources ailleurs ont changé d'avis à ce sujet, et maintenant j'utiliserai le mot "chemin complet" pour cela, "chemin" pour l'emplacement sans nom de fichier et "nom de fichier" ou "nom" pour le nom de fichier lui-même.
Nate
24

En C ++, Boost.Filesystem a conçu une nomenclature pour les différentes parties d'un chemin. Consultez la documentation de référence sur la décomposition des chemins pour plus de détails, ainsi que ce didacticiel .

Voici un résumé basé sur le tutoriel. Pour:

  • Chemin Windows: c:\foo\bar\baa.txt
  • Chemin Unix: /foo/bar/baa.txt

vous obtenez:

Part            Windows          Posix
--------------  ---------------  ---------------
Root name       c:               <empty>
Root directory  \                /
Root path       c:\              /
Relative path   foo\bar\baa.txt  foo/bar/baa.txt
Parent path     c:\foo\bar       /foo/bar
Filename        baa.txt          baa.txt
Stem            baa              baa
Extension       .txt             .txt

Norme C ++ ISO / IEC 14882: 2017

De plus, la terminologie Boost.Filesystem a été adoptée par C ++ 17 => Voirstd::filesystem

Function name     Meaning
----------------  -------------------------------
root_name()       Root-name of the path
root_directory()  Root directory of the path
root_path()       Root path of the path
relative_path()   Path relative to the root path
parent_path()     Path of the parent path
filename()        Path without base directory (basename)
stem()            Filename without extension
extension()       Component after last dot
Emile Cormier
la source
6
Comment appellent-ils la chose entière alors? path, fullpath?
wisbucky
@wisbucky Le tout est appelé "chemin" dans leur nomenclature.
Emile Cormier
1
@wisbucky Correction du lien. Merci.
Emile Cormier
@olibre: Merci pour la mise à jour C ++ 17. Mais stem()fait partie du nom de fichier , pas du chemin .
Emile Cormier
1
@ johnc.j. C'est dommage que Boost ne soit pas aussi bien connu lorsque la question a été posée pour la première fois. Je préfère adopter la nomenclature d'une bibliothèque évaluée par des pairs que de créer quelque chose par moi-même.
Emile Cormier
9

La pathlibbibliothèque standard de Python a une excellente convention de dénomination pour les composants de chemin: https://docs.python.org/3/library/pathlib.html

a) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src

tige

b) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

Nom

c) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo. src (sans point)

[rien]

d) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src (avec point)

suffixe

e) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin des grands parents

f) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin relatif vers le chemin du grand parent

g) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

nom du parent

h) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin parent

i) C: \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src

chemin

Maggyero
la source
8

Non tu n'es pas fou.

Dans les systèmes Windows, le chemin du répertoire contenant le fichier est parfois appelé chemin , tel qu'il était depuis le début. Ainsi, par exemple,

    x:\dir1\dir2\myfile.txt

    Windows:
    --------
        PATH:  x:\dir1\dir2
        FILE:  myfile.txt

    Unix/Linux:
    -----------
        PATH:  /dir1/dir2/myfile.txt
        FILE:  myfile.txt

L'approche Unix / Linux est beaucoup plus logique, et c'est ce que tout le monde a mentionné ci-dessus: chemin incluant le nom du fichier lui-même. Cependant, si vous tapez "call /?" dans la ligne de commande Windows, vous obtenez ceci:

    %~1         - expands %1 removing any surrounding quotes (")
    %~f1        - expands %1 to a fully qualified path name
    %~d1        - expands %1 to a drive letter only
    %~p1        - expands %1 to a path only
    %~n1        - expands %1 to a file name only
    %~x1        - expands %1 to a file extension only

Voilà, "chemin uniquement" et "nom de fichier uniquement". En même temps, ils se réfèrent à la chaîne entière en tant que "nom de chemin d'accès complet", ce qui est compris comme une lettre de lecteur plus un chemin plus un nom de fichier. Il n'y a donc pas de vraie vérité. C'est futile. Vous avez été trahi.

En tous cas,

Pour répondre à ta question

Voici comment je nommerais vos exemples:

A: -
B: basename
C: extension
D: -
E: -
F: -
G: -
H: pathname (or dirname or containing path)
I: full name

L'ADEF n'a pas de surnoms simples. Et comme php est probablement le langage multiplateforme le plus connu, tout le monde comprend "nom de base" et "nom de répertoire", donc je m'en tiendrai à cette dénomination. Le nom complet est également évident; le chemin complet serait un peu ambigu mais la plupart du temps cela signifie la même chose.

dkellner
la source
1
Depuis longtemps, j'utilise le mot "chemin d'accès" pour désigner le chemin absolu complet, y compris le nom de fichier complet. D'autres réponses ici et d'autres ressources ont changé d'avis à ce sujet, et maintenant j'utiliserai le mot "chemin complet" pour cela, "chemin" pour l'emplacement sans nom de fichier et "nom de fichier" ou "nom" pour le nom de fichier lui-même.
Nate