Lorsqu'un chemin d'accès à un répertoire est défini comme variable ou constante, doit-il se terminer par une barre oblique ? Quelle est la convention ?
pwd sous Unix affiche votre répertoire actuel sans barre oblique, tandis que la tabulation complète de cd /var/www/apps/ inclut la barre oblique, ce qui m'a laissé dans l'incertitude.
Peut-être devriez-vous réfléchir à ce que votre décision signifierait pour les dossiers. Si vous n'incluez pas la barre oblique à la fin d'un fichier répertoire vous devrez l'ajouter au début du fichier fichier nom.
Maintenant, si pour une raison quelconque, le chemin menant au fichier est manquant lorsque vous concaténérez des chaînes, vous obtenez quelque chose comme /filename qui n'est pas seulement un fichier, mais un chemin absolu à partir du répertoire racine (quel qu'il soit dans ce contexte).
C'est pourquoi je termine mes chemins d'accès par une barre oblique et je conserve les fichiers en tant que tels.
Je suppose qu'il s'agit de l'un de ces rares cas où la réponse correcte en théorie et en pratique est différente.
Il semble que @Karl Wilbur 's répondre est certainement correcte d'un point de vue théorique, car vous devriez être en mesure de distinguer une référence au nœud du répertoire lui-même du contenu du répertoire.
Mais dans la pratique, je dirais que la bonne réponse est l'inverse :
La raison la plus importante est que vous pouvez savoir avec certitude que le chemin /home/FSObjectX/ est un dossier, tandis que /home/FSObjectX est ambiguë. Personne ne peut dire s'il s'agit d'un fichier ou d'un dossier.
Les spécifications doivent toujours être précises et non ambiguës dans la mesure du possible.
Dans la grande majorité des cas, vous ferez toujours référence au contenu d'un dossier, et non au nœud dir lui-même.
Dans les rares cas où c'est le cas, il est facile de le gérer dans le code en supprimant tout séparateur de répertoire facultatif à la fin.
L'utilisation d'un double séparateur de dir ne fera pas de mal, mais l'absence d'un séparateur de dir en fera certainement.
En théorie, c'est un mauvais argument, car il ne faut pas coder par "hasard", mais en pratique, des erreurs se produisent, et l'utilisation de dir-sep à la fin pourrait peut-être réduire le nombre d'erreurs d'exécution pour l'utilisateur final.
En lisant cet intéressant fil de discussion, je n'ai pas trouvé d'inconvénients à l'utilisation de dir-sep en fin de ligne, seulement que c'est faux d'un point de vue théorique. Ou ai-je raté quelque chose ?
En php, la fonction dirname(__FILE __) renvoie le nom du répertoire sans barre oblique à la fin. J'ai tendance à m'en tenir à cette convention.
Sinon, l'utilisation d'une barre oblique à la fin d'un nom de répertoire entrera en conflit avec le fonctionnement de dirname(..) et vous serez alors obligé de gérer les deux cas puisque vous ne saurez pas si le nom du répertoire provient d'une fonction dirname(..) ou d'un contenu défini avec une barre oblique à la fin.
En bref : N'utilisez pas de barre oblique finale puisque dirname( ) ne le fait pas.
// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!Pour les autres langues, vérifiez la fonction qui extrait un nom de chemin, et voyez si elle utilise une barre oblique de fin ou non, puis respectez la convention de la langue.
Je sais qu'il s'agit d'un vieux sujet, mais j'ai pensé partager ce que je fais. Si possible, j'autoriserais normalement les deux et je ferais quelque chose comme ça (si c'était PHP) :
$fullPath = rtrim($directory, '/') . '/filename.txt');Ainsi, si le répertoire est défini dans un fichier de configuration, il importe peu que la personne qui le modifie ensuite inclue ou non la barre oblique.
J'ai tendance à n'ajouter que la barre oblique finale car il est plus que probable que j'utiliserai ce répertoire pour ajouter/récupérer des fichiers...
En ce qui concerne le référencement sur le web, il est possible d'améliorer les performances en laissant la barre oblique de fin de ligne dans le champ
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
