Praktische Überlegungen zu HTML / CSS-Namenskonventionen (Syntax) [geschlossen]

28

Frage: Wie lauten die praktischen Überlegungen zu Syntax classund idWerten?

Beachten Sie, dass ich nicht nach der Semantik frage , dh nach den tatsächlich verwendeten Wörtern, wie sie beispielsweise in diesem Blogpost beschrieben sind . Auf dieser Seite der Namenskonventionen gibt es bereits viele Ressourcen, die meine Suche nach praktischen Informationen zu den verschiedenen syntaktischen Elementen verdecken : Groß- und Kleinschreibung, Verwendung von Interpunktionen (insbesondere der -Bindestrich), bestimmte zu verwendende oder zu vermeidende Zeichen usw.

Um die Gründe zusammenzufassen, warum ich diese Frage stelle:

  • Die Namensbeschränkungen auf id und Klasse natürlich nicht zu irgendwelchen Konventionen führen
  • Die Fülle an Ressourcen auf der semantischen Seite von Namenskonventionen verdeckt die Suche nach syntaktischen Überlegungen
  • Ich konnte keine autorisierende Quelle dazu finden
  • Es gab noch keine Fragen zu SE Programmers zu diesem Thema :)

Einige der Konventionen, über die ich nachgedacht habe:

  1. UpperCamelCase, hauptsächlich als Cross-Over-Gewohnheit von serverseitiger Codierung
  2. lowerCamelCase, um die Übereinstimmung mit den JavaScript-Namenskonventionen zu gewährleisten
  3. css-style-classesDies entspricht der Benennung von CSS-Eigenschaften (kann jedoch ärgerlich sein, wenn Sie die Tastenkombination Strg + Umschalt + Pfeil drücken).
  4. with_under_scores, die ich persönlich nicht viel gebraucht gesehen habe
  5. alllowercase, einfach zu merken, aber für längere Namen schwer zu lesen
  6. UPPERCASEFTW, um Ihre Programmierkollegen zu ärgern (möglicherweise in Kombination mit Option 4 zur besseren Lesbarkeit)

Und wahrscheinlich habe ich auch einige wichtige Optionen oder Kombinationen ausgelassen. Also: Welche Überlegungen gibt es zur Benennung von Konventionen und zu welchen Konventionen führen sie?

Jeroen
quelle
CamelCaseEverythingInCode
Ryathal
11
ABER_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)
Jeroen
Ich schreibe normalerweise Kleinbuchstaben und CamelCase alles andere. Kein besonderer Grund
Antarr Byrd
"css-style-classes, die mit der Benennung von css-Eigenschaften übereinstimmen (aber bei der Auswahl von Text mit Strg + Umschalt + Pfeiltaste ärgerlich sein können)" - ist nur dann ein Problem, wenn Sie einen suboptimalen Texteditor verwenden
;-)
@Ryathal das ist PascalCase (oder UpperCamelCase), camelCase (oder lowerCamelCase) sieht so ausBeispiel.
Danny Varod

Antworten:

18

Kopfgeld oder nicht, bis zu einem gewissen Grad wird die Wahl immer eine "Präferenzsache" sein - wie würden Sie sich fühlen, wenn das W3C eine bestimmte Konvention empfiehlt (oder sogar auferlegt), die Sie nicht für richtig hielten?

Allerdings bevorzuge ich persönlich die lowerCamelCaseKonvention und gebe die Gründe und praktischen Überlegungen an, die ich verwendet habe, um mich zu entscheiden - ich werde dies durch einen Ausschlussprozess tun, wobei ich die Nummerierung aus Ihrer Frage verwende:

(5.) nur nicht leicht lesbar, da nicht bekannt ist, wo die Wörter beginnen und enden.

(6.) ASABOVEPLUSITSANNOYINGLIKEONESHOUTING.

(4.) history_incompatibility_plus_see: Mozilla Dev Documentation .

(3.) ein bisschen schwieriger zu erklären ... Wie Sie bereits erwähnt haben, ist die Auswählbarkeit in Texteditoren ein Problem (wie bei Unterstrichen, je nach Editor), aber für mich ist es auch die Tatsache, dass es mich an etwas erinnert Die Syntax ist für herstellerspezifische Schlüsselwörter reserviert , auch wenn diese mit einem Bindestrich beginnen und durch Wörter getrennt sind.

So bleiben Ihre (1.) und (2.), UpperCamelCase und LowerCamelCase. Trotz der mentalen Verbindung zu Java- Klassen (nach einer klareren Definition UpperCamelCase) sind CSS-Klassennamen meiner Meinung nach besser geeignet, mit einem Kleinbuchstaben zu beginnen. Möglicherweise liegt das an den Namen der XHTML-Elemente und -Attribute , aber ich denke, Sie könnten auch den Fall herbeiführen, dass die Verwendung von UpperCamelCase durch CSS-Klassen dazu beiträgt, diese voneinander zu unterscheiden. Wenn Sie einen anderen Grund benötigen, verwendet das W3C lowerCamelCase in Beispielen für gute Klassennamen (obwohl die URL selbst ärgerlicherweise nicht mit mir übereinstimmt ).

Ich würde aus den oben genannten Gründen von (4.), (5.) und (6.) abraten, nehme jedoch an, dass für die anderen drei Argumente vorgebracht werden könnten.

Ob Sie (oder sonst jemand) in dieser Angelegenheit mit mir einverstanden sind, liegt jedoch bei Ihnen. Die Tatsache , dass Sie keine bekamen definitive Antwort zitiert zuverlässige Quellen jetzt kann als Hinweis genommen werden , dass es nicht ist so etwas wie eine bestimmte Norm zu diesem Thema (sonst würden wir es alle verwenden). Ich bin mir nicht sicher, ob das unbedingt eine schlechte Sache ist.

Amos M. Carpenter
quelle
Vielen Dank! Sie erwähnen (wie die meisten anderen Antworten), dass dies eine Frage der Präferenz ist, ergänzen dies aber auch mit einigen praktischen Ratschlägen und einigen guten Links zu den wichtigeren Überlegungen (wie der one_on_icompatability). Obwohl ich immer noch überlege, dem Vorschlag in der Antwort von @tdammers (Benennung mit Bindestrichen) zu folgen, ist die hier gegebene Antwort diejenige, die die von mir gestellte Frage tatsächlich beantwortet. Also: Kopfgeld + akzeptiert, plus vielen Dank :)
Jeroen
Vielen Dank zurück - solange Sie konsequent bleiben, denke ich, dass alle drei in Ordnung sind. Es gibt nicht viel zwischen ihnen, und wenn Sie sich Websites im Internet ansehen, werden Sie sicher jede Menge Beispiele finden ;-)
Amos M. Carpenter
+1 Aber ich bin mir sicher, dass es unbedingt eine schlechte Sache ist. Während ich alle für Gemeinschaft getrieben Standards Bemühungen auf Namensgebung bin, Formatierung und allgemeine Stil Konventionen, kann der Mangel an Einheitlichkeit Projekt Vererbung ein Alptraum machen ( nicht würde sagen , dass ein solcher Alptraum von Standards gelindert werden, würden sie wahrscheinlich nicht gefolgt ) die Tatsache , dass CSS, schwach und deklarative, wird so mit Client verwirbelt und serverseitigen Anwendungslogik auch als einfacher Haken, sehnt sich es für die einheitliche Struktur ( indem sie sie sehnt sich, ich meine , ich sehne mich )
Dan Lugg
Ich stimme definitiv zu, dass Unterstriche vermieden werden sollten (außer vielleicht für ID-Namen, wenn Ihr serverseitiger Code Unterstriche verwendet). Bindestriche können in Programmiersprachen nicht als Trennzeichen verwendet werden, da der Bindestrich auch der Minus-Operator ist. Aber in jedem anderen Kontext, in dem Sie möglicherweise Unterstriche verwenden, sind Bindestriche meiner Meinung nach eine natürlichere Wahl - einfacher einzugeben und für URLs sichtbarer, wenn eine URL unterstrichen ist.
Matt Browne
7

Wörter in CSS-Klassennamen sollten mit Bindestrichen ( class-name) getrennt werden, da Wörter in CSS-Eigenschaften und Pseudoklassen auf diese Weise getrennt werden und ihre Syntax durch die CSS-Spezifikationen definiert wird .

Wörter in ID-Namen sollten auch mit Bindestrichen getrennt werden, um dem syntaktischen Stil von Klassennamen zu entsprechen, da ID-Namen häufig in URLs verwendet werden und der Bindestrich das ursprüngliche und häufigste Worttrennzeichen in URLs ist.

Emanuil Rusev
quelle
Ah + 1, ich mag die Erwähnung von IDs in URLs. Obwohl das Lustige daran ist, ein bisschen herumzustöbern, habe ich nachgesehen, wie Wikipedia das macht. Zum Beispiel die Browswer Unterstützung gab Abschnitt der Wikipedia CSS Artikel: <span id="Browser_support" class="mw-headline">Browser support</span>: O
Jeroen
3

Es ist meistens eine Frage der Präferenz; Es gibt keinen festgelegten Standard, geschweige denn eine maßgebliche Quelle in dieser Angelegenheit. Verwenden Sie, womit Sie sich am wohlsten fühlen. Sei einfach konsequent.

Ich persönlich benutze css-style-with-dashes, aber ich versuche, Mehrwortklassennamen zu vermeiden und, wo immer möglich, mehrere Klassen zu verwenden (also button important defaultnicht button-important-default). Aus meiner Erfahrung scheint dies auch die beliebteste Wahl unter qualitativ hochwertigen Websites und Frameworks zu sein.

Kleinbuchstaben mit Bindestrichen sind auch einfacher nowordseparatorswhatsoevereinzugeben als die anderen Optionen (mit Ausnahme der schwer lesbaren Konvention), zumindest auf US-Tastaturen, da die Umschalttaste nicht erforderlich ist.

Für IDs gibt es die zusätzliche praktische Überlegung, dass, wenn Sie Elemente anhand ihrer ID direkt in Javascript referenzieren möchten (z. B. document.forms[0].btn_ok), Bindestriche nicht so gut funktionieren - aber wenn Sie jQuery verwenden, werden Sie wahrscheinlich dies tun benutze sie $()trotzdem durch , dann kannst du sie einfach haben $('#btn-ok'), was diesen Punkt meistens umstritten macht.

Für das Protokoll, eine andere Konvention ich über kommen regelmäßig verwendet ungarischen Warzen in IDs den Elementtyp , um anzuzeigen, insbesondere für Formular - Steuerelemente - so müssten Sie #lblUsername, #tbUsername, #valUsernamefür den Benutzernamen Etikett, Eingang und Validator.

tdammers
quelle
Danke für die Antwort! Ich werde allerdings ein Kopfgeld setzen, in der Hoffnung, dass jemand eine Antwort hat, die dies weniger zu einer "Frage der Präferenz" macht. Wenn jedoch keine auftaucht, werde ich Ihre Antwort mit Sicherheit annehmen.
Jeroen
2

Ich bin der festen Überzeugung, dass die Konsistenz das Wichtigste ist.

Es gibt zwei Möglichkeiten, dies zu betrachten:

  1. Ein gutes Argument kann für alllowercaseoder css-style-clauses(wahrscheinlich die bessere Wahl) sein, weil sie mit dem Code, in dem sie sich befinden, am konsistentesten sind. Es verleiht dem Code insgesamt einen natürlicheren Fluss, und nichts wird verwirrend oder fehl am Platz sein .

  2. Ein ebenso gutes Argument für einen Stil, der sich von HTML-Tag-Namen oder CSS-Klauseln unterscheidet, ist die Unterscheidung von IDs und Klassen, um die Lesbarkeit zu verbessern. Wenn Sie beispielsweise UpperCamelCasefür IDs und Klassen verwendet haben und es nicht für ein anderes Konstrukt oder einen anderen Zweck verwendet haben, würden Sie wissen, dass Sie jedes Mal, wenn Sie ein Token in diesem Format sahen, auf eines gestoßen sind. Eine Einschränkung, die dies auferlegen könnte, ist, dass es am effektivsten wäre, wenn jede ID oder Klasse ein Name mit mehr als 2 Wörtern wäre, aber das ist in vielen Fällen vernünftig.

Als ich diese Antwort aufschrieb, stellte ich fest, dass ich eher zur zweiten Wahl neige, aber ich werde beide verlassen, weil ich denke, dass beide Fälle von Nutzen sind.

asfallows
quelle
-1

Es ist wirklich alles eine Frage der Präferenz oder der Faulheit. CamelCase ist einfacher zu tippen, aber ich bevorzuge die Verwendung der Unterstreichungsnotation, da ich persönlich das Lesen und Debuggen einfacher finde als CamelCase. Es gibt keine festgelegte Kodierungskonvention, die eingehalten werden muss. Ich habe noch nie an einem Ort gearbeitet, der die gleichen Kodierungsrichtlinien wie der Ort zuvor hatte.

Die meisten Unternehmen haben Richtlinien, an die Sie sich im Allgemeinen halten müssen, um den Code sauber zu halten und die Arbeit für alle zu erleichtern. Wenn Sie ein Freiberufler sind, können Sie alles daran setzen, da Sie die einzige Person sind, die an dem Code arbeitet. Meiner Meinung nach gibt es nur zwei Kodierungskonventionen: CamelCase- oder Unterstreichungsnotation. Mein Rat ist, einen auszuwählen und dann dabei zu bleiben.

Dwayne Charrington
quelle
-3

Sie scheinen sich einer einfachen Tatsache nicht bewusst zu sein: Die meisten CSS-Funktionen werden nicht von Programmierern ausgeführt .

Es wird von Grafikdesignern gemacht.

Sie kümmern sich nicht um unsere Bearbeitungskriege und sie kümmern sich nicht weniger darum, was wir mit der Umschalttaste machen.
Sie wissen wahrscheinlich nicht einmal, wo dieser schicke _Schlüssel ist . (oder wie es heißt)

Sie interessieren sich nicht für Code-Ästhetik , sie interessieren sich für ästhetische Ästhetik .

(Und sie können dort einen Punkt haben)

Sie lesen die Spezifikation nicht , sie erhalten das Tutorial.
Und dann überprüfen Sie die Referenzen auf w3schools.

Einige von ihnen glauben wahrscheinlich, dass sie aus Gründen keine großen Klassennamen verwenden können.
Sie stecken voller seltsamer, meist irrelevanter Missverständnisse.

ZJR
quelle
3
Ich denke, das hängt davon ab, wo Sie arbeiten. Ich habe mit Designern zusammengearbeitet, die ziemlich militant in Bezug auf Standards sind. Nach den Klängen von Dingen, die Sie gewohnt sind, mit unerfahrenen Front-End-Entwicklern oder Druckdesignern zu arbeiten, die sich als Webdesigner tarnen. Außerdem mache ich eine angemessene Menge an CSS für meine Projekte, ebenso wie einige meiner Kollegen bei der Arbeit. Ich denke, dass die Aufteilung von Design und Programmierung wirklich von der Unternehmensdynamik abhängt.
Ed James