Czy istnieje konwencjonalny sposób łączenia ciągów ścieżek plików?

W przykładzie:

var assets = "images/"

var sounds = assets+"sounds/"

Czy bardziej konwencjonalne jest umieszczanie ukośnika z tyłu ścieżki do pliku?

var assets = "/images"

var sounds = assets+"/sounds"

Czy istnieje inna metoda, która jest dobrą powszechną praktyką?

Prawie każdy główny język programowania ma bibliotekę do obsługi separatorów katalogów. Powinieneś je wykorzystać. Uprości to Twój kod i zapobiegnie błędom .

Z mojego doświadczenia wynika, że ​​typowym powodem łączenia takich ciągów jest to, że pochodzą one z różnych źródeł. Czasami różni się od pliku konfiguracyjnego. Czasami jest to ciągłe łączenie z argumentem funkcji. We wszystkich przypadkach, gdy pochodzą one z różnych źródeł, należy rozważyć kilka różnych możliwych przypadków dotyczących separatorów na końcach, które należy połączyć:

• Oba końce mogą mieć separator: "images/"i"/sounds"
• Tylko jeden ma separator: "images"i "/sounds"lub "images/"i"sounds"
• Żaden nie ma separatora: "images"i"sounds"

Fakt, że każda część pochodzi z innego źródła, oznacza, że ​​każde źródło może mieć własne wyobrażenia o konwencjach, których należy przestrzegać, jeśli ktoś w ogóle o tym pomyśli! Cokolwiek wywołuje Twój kod, nie powinno się o to martwić . Twój kod powinien obsłużyć wszystkie sprawy, ponieważ ktoś naruszy twoją konwencję . Spowoduje to, że stracisz czas na zbadanie przyczyny błędu i naprawę. Miałem kilka nieprzyjemnych okazji, w których współpracownik zakładał, jak należy sformatować ścieżki w pliku konfiguracyjnym, co oznacza, że ​​musiałem poszukać kodu i dowiedzieć się, czego się spodziewali (lub naprawić kod).

Większość głównych języków udostępnia dla ciebie metodę, która już obsługuje wiele przypadków:

• os.path.join dla Pythona
• File.join dla Ruby
• Path.join dla Node.js
• Paths.get dla Java (7 i więcej)
• Path.Combine dla .NET

Jest z nimi zastrzeżenie. Wiele z nich wydaje się zakładać, że wiodący separator katalogu w drugim argumencie odnosi się do ścieżki katalogu głównego i że oznacza to, że pierwszy argument powinien zostać całkowicie usunięty. Nie wiem, dlaczego uważa się to za przydatne; dla mnie to po prostu powoduje problemy. Nigdy nie chciałem łączyć dwóch części ścieżki i kończyć zrzucaniem pierwszej części. Przeczytaj uważnie dokumentację dotyczącą specjalnych przypadków, a jeśli to konieczne, napisz opakowanie, które robi to, co chcesz, zamiast ich specjalnej obsługi.

Pomaga to dodatkowo, jeśli potrzebujesz obsługi różnych systemów operacyjnych. Klasy te niemal powszechnie uwzględniają wybór właściwego separatora. Biblioteki zwykle mają sposób na znormalizowanie ścieżek, aby pasowały również do konwencji systemu operacyjnego.

W przypadku, gdy Twój język programowania nie ma łatwo dostępnej biblioteki, powinieneś napisać metodę, która obsługuje wszystkie te przypadki i używać jej swobodnie w różnych projektach.

Należy to do kategorii „nie rób założeń” i „używaj narzędzi, które ci pomogą”.

W Javie odpowiedzią byłoby „żadne z powyższych”. Najlepszą praktyką byłoby gromadzenie nazw ścieżek za pomocą java.io.Fileklasy; na przykład

File assets = new File("images");
File sounds = new File(assets, "sounds");

FileKlasa dba również platformy specyficzne separatorów ścieżki dostępu.

Istnieje osobna kwestia, czy nazwa ścieżki powinna zaczynać się od ukośnika, czy nie. Ale to bardziej dotyczy poprawności niż najlepszych praktyk. Nazwa ścieżki zaczynająca się od ukośnika oznacza coś innego niż nazwa ścieżki, która nie !!

Nie ma wyraźnego wsparcia dla obsługi nazw ścieżek w podstawowej bibliotece JavaScript (ECMA), ale (przynajmniej) Node.js zapewnia wsparcie poprzez moduł Path.

Zauważ, że w .NET powinieneś użyć metody Path.Combine.

var path = System.IO.Path.Combine("assets", "sounds");

Powodem tego jest to, że „zna” prawidłowe znaki, które mają być użyte podczas konstruowania nazw folderów.

Eliminuje to „problem” wstępnego lub końcowego naprawiania.

Podczas budowania ścieżek często używam funkcji, która dodaje ukośnik, jeśli jeszcze go nie ma. Następnie można zbudować ścieżki:

filename := fs( 'assets') + fs( 'images') + fs( 'icons') + 'some.png';

gdzie fs () dodaje ukośnik końcowy, jeśli jest potrzebny.

Foldery i pliki różnią się tylko jednym aspektem: foldery kończą się ukośnikiem, a pliki nie. Ponadto ścieżki bezwzględne rozpoczynają się od /ścieżek względnych, w których nie. Jeśli użyjesz tego konsekwentnie łącząc ścieżki i pliki razem, nie powinno to stanowić problemu.

var absolutepath = "/my/path/";
var relativepath = "css/";
var filename = "test.css";
var relativepathtofilename = "js/test.js";

var a = absolutepath + relativepath + filename; //Output: /my/path/css/test.css
var b = absolutepath + relativepathtofilename;  //Output: /my/path/js/test.js

Łączenie dwóch absolutnych ścieżek razem nie ma sensu, ponieważ druga ścieżka powinna być względna do pierwszej ścieżki. Łączenie dwóch ścieżek względnych razem nie stanowi problemu, ale może prowadzić do nieokreślonego zachowania, jeśli program nie wie, gdzie ścieżka względna jest względna.

Myślę, że nie ma magii ani „powszechnej praktyki” w zakresie wdrażania ścieżek, ale z pewnością łączenie łańcuchów nie jest właściwą drogą. Możesz opracować własny interfejs API do obsługi spraw, ale może to wymagać pewnego wysiłku. W szczególności należy zachować ostrożność w przypadku różnych platform. Na przykład w Windows \jest separatorem, podczas gdy w systemach uniksowych /jest separatorem.

Nie znam bibliotek Javascript, ale jestem pewien, że powinny istnieć biblioteki do obsługi tych przypadków. Na przykład w Javie można użyć interfejsu API ścieżki do obsługi niezależnych od platformy operacji na ścieżkach.

Moje osobiste preferencje są następujące:

var assets = "/images"

var sounds = assets+"/sounds"

Zawsze używam ścieżek bezwzględnych ( /images/...), dla mnie jest to mniej podatne na błędy. Jest to również bardziej głupi dowód na użycie, var sounds = assets+"/sounds"ponieważ nawet jeśli assetsmiałbyś końcowy ukośnik i skończyłbyś z /images//soundsnim, nadal by to rozwiązał /images/sounds. Jedynym zastrzeżeniem jest to, że zależy to od obsługi żądania. Wydaje się, że Apache dobrze sobie z tym radzi (przynajmniej niektóre wersje / konfiguracje, patrz http://www.amazon.com//gp//site-directory//ref=nav_sad ). W inny sposób, w jaki byś skończył /imagessounds, nie tak głupi dowód :) Istnieje również możliwość sprawdzenia podwójnych ukośników i ich wyczyszczenia. W przypadku drugiego podejścia nie ma takiej opcji.

W Smalltalk łatwo jest zdefiniować metodę / w String, aby działała w następujący sposób:

'assets' / 'sounds' => 'assets/sounds'.
'assets/' / 'sounds' => 'assets/sounds'.
'assets' / '/sounds' => 'assets/sounds'.
'assets/' / '/sounds' => 'assets/sounds'.

Oto prosta implementacja metody (możesz ją ulepszyć):

/ aString
    | slash first second |
    slash := Directory separator.
    first := self.
    (first endsWith: slash) ifTrue: [first := first allButLast].
    second := aString.
    (second beginsWith: slash) ifTrue: [second := second allButFirst].
    ^first , slash , second

Uwaga : możesz również zapłacić większą uwagę na przypadki graniczne, takie jak '' / '', 'x/' / ''itd, w celu określenia właściwego zachowania.