Praktyczne uwagi dotyczące konwencji nazewnictwa HTML / CSS (składnia) [zamknięte]


28

Pytanie: jakie są praktyczne względy dotyczące składni classi idwartości?

Zauważ, że nie pytam o semantykę , czyli o rzeczywiste używane słowa, jak na przykład opisano w tym blogu . Istnieje wiele zasobów po tej stronie konwencji nazewnictwa, w rzeczywistości zaciemniając moje poszukiwanie praktycznych informacji na temat różnych bitów składniowych : obudowa, użycie interpunkcji (w szczególności -myślnik), konkretnych znaków do użycia lub uniknięcia itp.

Podsumowując powody zadaję to pytanie:

  • Nazewnictwie ograniczenia dotyczące id i klasy naturalnie nie prowadzą do żadnych konwencjach
  • Obfitość zasobów po semantycznej stronie konwencji nazewnictwa zaciemnia poszukiwania w kwestiach składniowych
  • Nie mogłem znaleźć na to żadnego wiarygodnego źródła
  • Nie było jeszcze żadnych pytań na temat programistów SE na ten temat :)

Niektóre konwencje, które rozważałem przy użyciu:

  1. UpperCamelCase, głównie jako cross-over habit z kodowania po stronie serwera
  2. lowerCamelCase, w celu zachowania spójności z konwencjami nazewnictwa JavaScript
  3. css-style-classes, co jest spójne z nazywaniem właściwości css (ale może być denerwujące, gdy zaznaczenie tekstu Ctrl + Shift + ArrowKey)
  4. with_under_scores, którego osobiście niewiele widziałem
  5. alllowercase, łatwe do zapamiętania, ale może być trudne do odczytania w przypadku dłuższych nazw
  6. UPPERCASEFTW, jako świetny sposób na zirytowanie innych programistów (być może w połączeniu z opcją 4 dla czytelności)

I prawdopodobnie pominąłem też kilka ważnych opcji lub kombinacji. Więc: jakie są rozważania dotyczące konwencji nazewnictwa i do jakiej konwencji prowadzą?


CamelCaseEverythingInCode
Ryathal

11
BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)
Jeroen

Zwykle małe litery i CamelCase wszystko inne. Bez konkretnego powodu
Antarr Byrd

„klasy w stylu css, co jest spójne z nazywaniem właściwości css (ale może być denerwujące, gdy zaznaczanie tekstu przez Ctrl + Shift + ArrowKey)” - stanowi problem tylko w przypadku korzystania z nieoptymalnego edytora tekstu ;-)
tdammers

@Ryathal, czyli PascalCase (lub UpperCamelCase), camelCase (lub lowerCamelCase) wygląda następująco:
Danny Varod

Odpowiedzi:


18

Bounty czy nie, do pewnego stopnia wybór zawsze będzie „kwestią preferencji” - w końcu, jak byś się czuł, gdyby W3C zalecił (a nawet narzucił) pewną konwencję, która według ciebie nie była słuszna?

Powiedziawszy to, osobiście wolę lowerCamelCasekonwencję i podam powody i względy praktyczne, o których się zdecydowałem - zrobię to poprzez proces eliminacji, wykorzystując numerację z twojego pytania:

(5.) Po prostu łatwo można go odczytać, ponieważ nie wiesz, jakie są słowa.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) historical_incompatibility_plus_see: Dokumentacja dewelopera Mozilla .

(3.) nieco trudniejsze do wyjaśnienia ... jak wspomniałeś, możliwość wyboru w edytorach tekstowych to jeden problem (jak w przypadku podkreślników, w zależności od edytora), ale dla mnie jest to również fakt, że przypomina mi składnia zarezerwowana dla słów kluczowych specyficznych dla dostawcy , nawet jeśli zaczynają się od myślnika, a także od siebie oddzielają słowa.

Pozostawia to odpowiednio: (1.) i (2.), UpperCamelCase i lowerCamelCase. Pomimo mentalnego linku do klas Java (które są, według bardziej precyzyjnie określonej konwencji, UpperCamelCase), nazwy klas CSS wydają mi się lepiej, zaczynając od małej litery. Być może dzieje się tak ze względu na nazwy elementów i atrybutów XHTML , ale myślę, że możesz również argumentować, że posiadanie klas CSS przy użyciu UpperCamelCase pomogłoby je rozdzielić. Jeśli potrzebujesz innego powodu, WCh wykorzystuje przykłady lowerCamelCase w przykładach dobrych nazw klas (chociaż sam URL, irytująco, nie zgadza się ze mną).

Odradzałbym (4.), (5.) i (6.) z powodów podanych powyżej, ale przypuszczam, że można argumentować w przypadku którejkolwiek z pozostałych trzech.

To, czy ty (lub ktokolwiek inny w tej sprawie) zgodzisz się ze mną w tej sprawie, zależy jednak od ciebie. Fakt, że do tej pory nie masz jednoznacznej odpowiedzi na cytowanie autorytatywnych źródeł, może być wskazówką, że nie ma czegoś takiego jak określony standard w tej kwestii (inaczej wszyscy byśmy go używali). Nie jestem pewien, czy to koniecznie zła rzecz.


Dzięki! Wspominasz (podobnie jak większość innych odpowiedzi), że jest to kwestia preferencji, ale także uzupełniasz ją praktycznymi poradami i kilkoma dobrymi linkami do ważniejszych kwestii (takich jak one_on_icompatability). Mimo że nadal rozważam skorzystanie z sugestii zawartej w odpowiedzi @tdammers (nazewnictwo z myślnikami), podana tutaj odpowiedź jest tą, która faktycznie odpowiada na pytanie, które zadałem. A więc: nagroda + przyjęta, plus wielkie podziękowania :)
Jeroen

Wielkie dzięki z powrotem - dopóki jesteś konsekwentny, myślę, że którekolwiek z tych trzech jest w porządku. Nie ma między nimi wiele, a jeśli spojrzysz na witryny w sieci, jestem pewien, że znajdziesz mnóstwo przykładów każdego z nich ;-)
Amos M. Carpenter

+1 Chociaż jestem pewien, że to zła rzecz. Chociaż jestem zwolennikiem standardów opartych na społeczności, dotyczących nazewnictwa, formatowania i ogólnych konwencji stylów , brak jednolitości może sprawić, że dziedziczenie projektu będzie koszmarem ( nie mówiąc, że taki koszmar zostałby złagodzony przez standardy, prawdopodobnie nie byłyby obserwowany ) Fakt, że CSS, słaby i deklaratywny, jest tak przeplatany z logiką aplikacji po stronie klienta i serwera, nawet jako proste haki, tęskni za ujednoliconą strukturą ( przez to tęskni, mam na myśli tęsknotę )
Dan Lugg

Zdecydowanie zgadzam się, że należy unikać znaków podkreślenia (z wyjątkiem być może nazw ID, jeśli kod po stronie serwera używa znaków podkreślenia). Łączników nie można używać jako separatora w językach programowania, ponieważ łącznik jest również operatorem minus. Ale w każdym innym kontekście, w którym można użyć podkreślników, myślę, że łączniki są bardziej naturalnym wyborem - łatwiejszy do wpisania, a dla adresów URL, bardziej widoczny, gdy URL jest podkreślony.
Matt Browne,

7

Słowa w nazwach klas CSS powinny być oddzielone myślnikiem ( class-name), ponieważ tak dzielą się słowa we właściwościach CSS i pseudoklasach, a ich składnię określa specyfikacja CSS .

Słowa w nazwach ID powinny być również oddzielone myślnikami, aby pasowały do ​​stylu składniowego nazw klas, ponieważ nazwy ID są często używane w adresach URL, a myślnik jest oryginalnym i najczęstszym separatorem słów w adresach URL.


Ah +1, podoba mi się wzmianka o identyfikatorach w adresach URL. Chociaż najśmieszniejsze jest to, że trochę się tym zajadam, poszłam sprawdzić, jak robi to Wikipedia. Na przykład sekcja wsparcia Browswer w artykule z Wikipedii CSS podała <span id="Browser_support" class="mw-headline">Browser support</span>: O
Jeroen

3

Jest to głównie kwestia preferencji; nie ma ustalonego standardu, a tym bardziej wiarygodnego źródła w tej sprawie. Używaj tego, co najbardziej ci odpowiada; po prostu bądź konsekwentny.

Osobiście używam css-style-with-dashes, ale staram się unikać nazw klas składających się z wielu słów i używam wielu klas tam, gdzie to możliwe ( button important defaultraczej niż button-important-default). Z mojego doświadczenia wynika, że ​​jest to również najpopularniejszy wybór wśród wysokiej jakości stron internetowych i platform.

Małe litery z myślnikami są również łatwiejsze do wpisania niż inne opcje (z wyjątkiem trudnej do odczytania nowordseparatorswhatsoeverkonwencji), przynajmniej na klawiaturach amerykańskich, ponieważ nie wymagają użycia klawisza Shift.

W przypadku identyfikatorów istnieje dodatkowa praktyczna uwaga, że ​​jeśli chcesz odwoływać się do elementów według ich identyfikatora bezpośrednio w javascript (np. document.forms[0].btn_ok), Myślniki nie będą działały tak dobrze - ale wtedy, jeśli używasz jQuery, prawdopodobnie używaj ich $()mimo to, więc możesz po prostu mieć $('#btn-ok'), co sprawia, że ​​ten punkt jest w większości dyskusyjny.

Dla przypomnienia, inna konwencja spotykam regularnie korzysta węgierskich brodawki w ID użytkownika, aby wskazać typ elementu, zwłaszcza dla pól formularza - tak trzeba było #lblUsername, #tbUsername, #valUsernamena etykiecie nazwę użytkownika, wejście i weryfikatora.


Dziękuję za odpowiedź! Zamierzam jednak wystawić nagrodę, mając nadzieję, że ktoś zna odpowiedź, która czyni to mniej „kwestią preferencji”. Jeśli nie pojawi się żaden, z pewnością zaakceptuję twoją odpowiedź.
Jeroen,

2

Mocno wierzę, że najważniejsza jest konsekwencja.

Są na to dwa sposoby:

  1. Można postawić dobry argument alllowercaselub css-style-clauses(prawdopodobnie lepszy wybór), ponieważ będą one najbardziej spójne z kodem, w którym się znajdą. Zapewni to bardziej naturalny przepływ kodu i nic nie będzie zgorszone lub nie na miejscu .

  2. Równie dobrym argumentem może być styl, który różni się od nazw znaczników HTML lub klauzul CSS, jeśli będzie różnicował identyfikatory i klasy w sposób ułatwiający czytelność. Na przykład, jeśli UpperCamelCaseużywałeś identyfikatorów i klas, a nie używałeś go do żadnej innej konstrukcji lub celu, wiedziałbyś, że trafiłeś na jeden za każdym razem, gdy zobaczyłeś token w tym formacie. Jednym z ograniczeń, które może to nałożyć, jest to, że najskuteczniej byłoby, gdyby każdy identyfikator lub klasa były nazwą składającą się z ponad 2 słów, ale w wielu przypadkach jest to uzasadnione.

Pisząc tę ​​odpowiedź doszedłem do wniosku, że jestem bardziej skłonny do drugiego wyboru, ale opuszczę oba, ponieważ uważam, że oba przypadki mają swoje zalety.


-1

To naprawdę kwestia preferencji lub lenistwa. CamelCasing jest łatwiejszy do pisania, ale wolę używać notacji podkreślenia, ponieważ osobiście łatwiej mi czytać i debugować niż CamelCase. Nie ma jednej ustalonej konwencji kodowania, której należy przestrzegać, nigdy nie pracowałem w miejscu, które miałoby takie same wytyczne kodowania jak miejsce przed nim.

Większość firm ma wytyczne, których na ogół musisz przestrzegać, aby utrzymać kod w czystości i ułatwić wszystkim pracę. Jeśli jesteś freelancerem, możesz wyjść na całość, ponieważ jesteś jedyną osobą pracującą nad kodem. Moim zdaniem są tylko 2 konwencje kodowania: notacja CamelCase lub Underscore. Radzę wybrać jedną, a następnie trzymać się jej.


-3

Wydajesz się nieświadomy jednego prostego faktu: większość CSS nie jest wykonywana przez programistów .

Robią to graficy.

Nie dbają o nasze wojny edytorskie i nie mogą mniej obchodzić tego, co robimy z klawiszem Shift.
Prawdopodobnie nawet nie wiedzą, gdzie jest ten wymyślny _klucz . (lub jak się nazywa)

Nie dbają o estetykę kodu , dbają o estetykę estetyczną .

(I mogą mieć rację)

Nie czytają specyfikacji , otrzymują samouczek.
A następnie dokładnie sprawdź referencje w w3schools.

Niektórzy z nich prawdopodobnie uważają, że z powodów nie mogą używać wielkich liter.
Są pełne dziwnych, przeważnie nieistotnych nieporozumień.


3
Myślę, że to zależy od tego, gdzie pracujesz. Pracowałem z projektantami, którzy dość walczą o standardy; Przy dźwiękach rzeczy, do których przywykłeś do pracy z niedoświadczonymi programistami front-end lub projektantami druku udającymi projektantów stron internetowych. Dodatkowo, robię rozsądną ilość CSS w swoich projektach, podobnie jak wielu moich rówieśników w pracy, myślę, że podział na projektowanie / programowanie naprawdę zależy od dynamiki firmy.
Ed James
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.