Adresy URL: Dash vs. Underscore [zamknięte]

Czy powinno to być / about_us lub / about-us ?

Z punktu widzenia użyteczności osobiście uważam, że / użytkownik jest o wiele lepszy dla użytkowników końcowych, ale Google i większość innych stron internetowych (i frameworki javascript) używają wzorca nazw podkreślenia. Czy to tylko kwestia stylu? Czy są jakieś problemy ze zgodnością z myślnikami?

To tylko przypuszczenie, ale wygląda na to, że wybrali ten, którego ludzie najprawdopodobniej nie użyliby w nazwie. W ten sposób możesz mieć nazwę zawierającą dzielony wyraz i nadal używać dolnego paska jako separatora słów, np. UseTwo-wayLinks można przekonwertować na use_two-way_links.

W twoim przykładzie / about-us byłby katalogiem o nazwie dzielonego wyrazu „about-us” (gdyby takie słowo istniało, a / about_us byłby katalogiem o nazwie składającej się z dwóch słów fraza „o nas” przekonwertowanym na pojedynczy ciąg znaków znaków innych niż białe.

Z Google Webmaster Central

Rozważ użycie interpunkcji w swoich adresach URL. Adres URL http://www.example.com/green-dress.html jest dla nas znacznie bardziej użyteczny niż http://www.example.com/greendress.html . Zalecamy stosowanie łączników (-) zamiast podkreślników (_) w adresach URL.

Oto kilka punktów na korzyść myślników:

• Google zaleca kreski zamiast podkreślników ( źródło ).
• Kreski są bardziej znane użytkownikowi końcowemu.
• Kreski są łatwiejsze do pisania na standardowej klawiaturze (nie ma potrzeby Shift).
• Kreski nie chowają się za podkreśleniami.
• Myślniki są bardziej natywne w kontekście adresów URL, ponieważ są dozwolone w nazwach domen.

To nie tylko myślnik vs. podkreślenie:

• tekst ze spacjami
• tekst bez przestrzeni
• zakodowane% 20spaces% 20in% 20URL
• underscore_means_space
• dash-znaczy-przestrzeń
• plus + oznacza + spację
• camelCase
• PascalCase
• „cytowany tekst ze spacjami” (i pojedynczy cytat vs. podwójny cytat)
• ukośnik / środki / spacja
• dot.means.space

Google nie traktował podkreślenia jako separatora słów w przeszłości, co moim zdaniem było dość szalone, ale najwyraźniej robi to teraz. Ze względu na tę historię preferowane są myślniki. Mimo że podkreślenia są teraz dozwolone z punktu widzenia SEO, nadal uważam, że kreski są najlepsze.

Jedną z korzyści jest to, że przeciętny internauta z pół-komputera, który jest analfabetą, jest o wiele bardziej skłonny do wpisania myślnika na klawiaturze, może nawet nie wiedzieć, co to jest podkreślenie.

Zawsze używałem podkreślników, teraz używam ich tylko do części strony internetowej, których nie chcę, aby ktokolwiek bezpośrednio łączył, pliki js, css, ... itd.

Z punktu widzenia SEO kreski wydają się być preferowanym sposobem radzenia sobie z nimi, dla szczegółowego wyjaśnienia, z ust koni http://www.mattcutts.com/blog/dashes-vs-underscores/ .

Innym problemem, który wydaje się występować, bardziej w przypadku ogółu społeczeństwa niż programistów, jest to, że gdy hiperłącze z podkreśleniami jest podkreślone, nie widać podkreślenia. Zaawansowani użytkownicy to wypracują, ale Joe Public prawdopodobnie tego nie zrobi.

Nadal jednak używaj podkreślenia w kodzie zamiast myślników - programiści je rozumieją, a większość innych ludzi tego nie rozumie.

Jeff ma przemyślenia na ten temat: https://blog.codinghorror.com/of-spaces-underscores-and-dashes/

Oba mają wady. Sugerowałbym wybranie jednego i zachowanie spójności.

Guru SEO Jim Westergren przetestował to w 2005 roku ze ścisłej perspektywy SEO i doszedł do wniosku, że + (plus) to tak naprawdę najlepszy separator słów. Nie wydaje się to jednak rozsądne i może być spowodowane błędem w algorytmach wyszukiwarek. Zaleca - (myślnik) ze względu na czytelność i SEO.

Czuję się lepiej z podkreśleniami. Po pierwsze, pasują one do mojego regularnego doświadczenia programistycznego variable_names_are_not-subtraction, po drugie, i wierzę, że zostało to już wspomniane, słowa mogą mieć myślniki, ale nigdy nie podkreślają. Aby wybrać naprawdę głupi przykład, „państwo narodowe” różni się od „państwo narodowe”. Ten pierwszy tłumaczy coś w rodzaju „krainy państw narodowych” (myślę, że „tu jest kraj z bronią! Najlepszy ruch, prawda?”), Podczas gdy drugi wygląda jak lista czasami-synonimów. http://example.com/nation-state-country/nie wydaje się oznaczać tego samego co http://example.com/nation-state_country/, a jednak, jeśli łączniki są ogranicznikami / „spacjami” oprócz znaków w słowach, może to zrobić. Ta ostatnia wydaje się bardziej jasna co do faktycznego celu, podczas gdy ta pierwsza wygląda bardziej jak ta lista, jeśli w ogóle.

Podkreślenia zastępują spacje, w których białe znaki nie są dozwolone. Myślniki (myślniki) mogą być częścią słowa, dlatego łączenie słów ze myślnikami, które już zawierają myślniki, jest brzydkie / mylące.

Zły:

/low-budget-movies

Dobry:

/low-budget_movies

Myślę, że dash jest lepszy z perspektywy użytkownika i nie będzie zakłócał SEO.

Nie jestem pewien, gdzie i dlaczego rozpoczęła się konwencja podkreślania.

Trochę bardziej kompetentna debata

Wolę myślniki na tej podstawie, że podkreślenie może być w pewnym stopniu zaciemnione przez podkreślenie linku. Tekstowe adresy URL służą przede wszystkim do rozpoznawania na pierwszy rzut oka, a nie do poprawności gramatycznej, dlatego argument dotyczący zachowania myślników do użycia w łączonych wyrazach jest ograniczony.

Tam, gdzie dokładność tekstowego adresu URL jest ważna, należy odczytać go komuś, w którym to przypadku nie chcesz mylić znaku podkreślenia dla spacji (lub odwrotnie).

Uważam też, że myślniki są bardziej estetyczne, jeśli to się liczy.

Dla widoku użytkownika końcowego wolę „o-nas” lub „o nas”, a nie „about_us”

Osobiście unikałbym używania about-us lub about_us i po prostu używałem about.

Niektóre starsze serwery hostingowe i serwery DNS mają problemy z analizowaniem znaków podkreślenia dla adresów URL, co może odgrywać rolę w takich konwencjach.

Osobiście unikałbym wszystkich myślników i podkreśleń i wybrałem camelCase lub PascalCase, jeśli jest w kodzie.

Artykuł w Wikipedii na temat camelCase wyjaśnia nieco przyczyny jego powstania. Wynoszą one

1. Leniwi programiści, którzy nie lubili sięgać po klawisz _
2. Potencjalne zamieszanie dotyczące czytelności
3. Klawiatura „Alto” ​​w Xerox PARC, która nie miała klawisza podkreślenia.

Jeśli użytkownik ma zobaczyć ciąg, nie zrobiłbym żadnego z powyższych i użyłbym słowa „O nas”. lub „AboutUs”, gdybym musiał, ponieważ camelCase rozprzestrzenił się do powszechnego użytku w niektórych obszarach, takich jak nazwy produktów. tj. ThinkPad, TiVo

Spacje są dozwolone w adresach URL, więc możesz po prostu użyć „/ about my” w linku (chociaż będzie to zakodowane w „/ około% 20us”. Ale szczerze mówiąc, zawsze będzie to osobista preferencja, więc nie ma prawdziwej odpowiedzi do podania tutaj.

Postawiłbym na konwencję, że myślniki mogą pojawiać się słowami, więc spacje powinny być zamieniane na podkreślenia.

Lepsze wykorzystanie. - / jako separatory, ponieważ _ wydaje się nie być separatorem.

http://www.sistrix.com/blog/832-how-long-may-a-linktext-be.html