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

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ą?

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.

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.

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.

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.

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.

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ń.