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ą?
conventions
file-structure
jairidescent
źródło
źródło
File.separator
,File
aPath
interfejsy API i akceptują zarówno, jak/
i `\`.Odpowiedzi:
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ć:
"images/"
i"/sounds"
"images"
i"/sounds"
lub"images/"
i"sounds"
"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 PythonaFile.join
dla RubyPath.join
dla Node.jsPaths.get
dla Java (7 i więcej)Path.Combine
dla .NETJest 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ą”.
źródło
C:\Documents and Settings\Admin
zmy folder:document.txt
systemem * nix do produkcji/home/admin/my folder/document.txt
- urocza sztuczka, ale w prawdziwym świecie heurystyka spowodowała więcej błędów niż naprawiła.Paths.get()
po prostu przekształca pojedynczy obiektString
wPath
obiekt. Do łączenia ścieżek użyjeszPath.resolve()
innej,Path
lub innejString
. WPath
klasie znajdują się inne metody, które pozwalają na łączenie ścieżek na różne sposoby.Paths
zbyt dobrze dokumentów .[System.IO.Path]::Combine("abc", "\def")
która ma opisane zachowanie, jest cmdlet,Join-Path "abc" "\def"
który daje"abc\def"
.W Javie odpowiedzią byłoby „żadne z powyższych”. Najlepszą praktyką byłoby gromadzenie nazw ścieżek za pomocą
java.io.File
klasy; na przykładFile
Klasa 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.
źródło
os.path.join
. PowerShell majoin-path
. Dodałbym coś do tej odpowiedzi. Odkryłem, że jeśli potrzebujesz ścieżek plików w wielu częściach, to sprawia, że twój kod jest bardzo delikatny, jeśli przyjmujesz założenia, że któreś z nich ma ścieżki plików w określonych miejscach. Korzystanie z tych klas nie tylko pomaga w przenoszeniu, ale także obsługuje wszystkie możliwe przypadki krawędzi (cięcie na obu końcach do połączenia, cięcie tylko na jednej stronie, bez żadnego cięcia między nimi). Ta elastyczność jest nieoceniona, gdy upuszczasz ścieżki do pliku konfiguracyjnego.Zauważ, że w .NET powinieneś użyć metody Path.Combine.
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.
źródło
os.path.join('src', '../../../your_secret_stuff')
jest poprawny w Pythonie; innymi słowy, nie używaj tych metod na ślepo na dane wprowadzone przez użytkownika.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:
gdzie fs () dodaje ukośnik końcowy, jeśli jest potrzebny.
źródło
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.Łą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.
źródło
var a = "/my/path" + "css/" + "test.css"; //Output: "/my/pathcss/test.css"
absolutepath
powinien zakończyć się ukośnikiem, ponieważ jest to ścieżka. Jakoś przeoczyłem to, kiedy to napisałem.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.
źródło
/
ogranicznik nazw plików. To wymaga dziwactwa w wierszu poleceń, ale interfejsy API we / wy plików działają dobrze z ukośnikiem do przodu.Moje osobiste preferencje są następujące:
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śliassets
miałbyś końcowy ukośnik i skończyłbyś z/images//sounds
nim, 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.źródło
/
) jest ścieżką bezwzględną , a nie ścieżką względną. Czy miałeś na myśli to tylko dla odcinków ścieżki innych niż pierwszy?/somewhere
jest to ścieżka względna, ponieważ nie zawiera hosta, więc przeglądarka będzie ją wyszukiwać na podstawie hosta bieżącej strony ... W świecie internetowymhttp://here/somewhere
jest bezwzględnym identyfikatorem URI i/somewhereelse
jest z nim związany. W świecie systemów plików/somewhere
jest absolutny, pochodzi z katalogu głównego/
, a „gdzieś” odnosi się do bieżącego katalogu roboczego.http://here/somewhere
jest identyfikatorem URI ze ścieżką bezwzględną,/somewhere
jest referencją względną ze ścieżką bezwzględną isomewhere/else
referencją względną ze ścieżką względną. Najwyraźniej w tych kręgach „ścieżka względna” jest używana w odniesieniu do odniesienia względnego.W Smalltalk łatwo jest zdefiniować metodę / w String, aby działała w następujący sposób:
Oto prosta implementacja metody (możesz ją ulepszyć):
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.źródło