Tl;dr;
Es gibt keine einzig wahre Antwort. Sie können einen der vielen Standards wählen oder Ihre eigenen Standards erstellen, je nachdem, mit wem Sie zusammenarbeiten. Und das ist zu 100 % abhängig von der Plattform.
Original-Post
Nur ein weiterer alternativer Standard, der in Betracht gezogen werden sollte:
<div id="id_name" class="class-name"></div>
Und in Ihrem Drehbuch:
var variableName = $("#id_name .class-name");
Hier wird lediglich ein camelCase, under_score bzw. hyphen-ation für Variablen, ids und Klassen verwendet. Ich habe über diesen Standard auf verschiedenen Websites gelesen. Obwohl ein wenig redundant in css/jquery-Selektoren, Redundanzen machen es einfacher, Fehler zu fangen. zB: Wenn Sie sehen .unknown_name o #unknownName in Ihrer CSS-Datei, wissen Sie, dass Sie herausfinden müssen, worauf sich das eigentlich bezieht.
UPDATE 2019
(Bindestriche werden als "Kebab-Case" bezeichnet, Unterstriche als "Snake_case", und dann gibt es noch "Title Case", "PascalCase" und "CamelCase")
Ich persönlich mag keine Bindestriche. Ursprünglich habe ich dies als eine Alternative gepostet (weil die Regeln einfach sind). Allerdings machen Bindestriche Auswahlkürzel sehr schwierig (Doppelklick, ctrl / option + left / right y ctrl / cmd + D in vsCode. Außerdem sind Klassennamen und Dateinamen die einzigen Orte, an denen Bindestriche funktionieren, weil sie fast immer in Anführungszeichen oder in CSS usw. stehen. Aber die Abkürzung Sache gilt immer noch.
Zusätzlich zu Variablen, Klassennamen und IDs sollten Sie auch die Konventionen für Dateinamen beachten. Und Git-Zweige.
Die Kodiergruppe meines Büros hatte vor ein oder zwei Monaten ein Treffen, um zu besprechen, wie wir die Dinge benennen wollten. Für Git-Zweige konnten wir uns nicht zwischen 321-the_issue_description und 321_the-issue-description entscheiden. (Ich wollte 321_theIssueDescription, aber das gefiel meinen Kollegen nicht.)
Ein Beispiel, um zu zeigen, wie man mit den Normen anderer Leute arbeitet...
Vue.js hat einen Standard. Eigentlich haben sie zwei alternative Standards für mehrere ihrer Elemente. Ich mag beide Versionen für Dateinamen nicht. Sie empfehlen entweder "/path/kebab-case.vue" o "/path/PascalCase.Vue" . Ersteres ist schwieriger umzubenennen, es sei denn, Sie wollen speziell einen Teil davon umbenennen. Letzteres ist nicht gut für die plattformübergreifende Kompatibilität. Ich würde bevorzugen "/path/snake_case.vue" . Wenn man jedoch mit anderen Personen oder bestehenden Projekten arbeitet, ist es wichtig, sich an den bereits festgelegten Standard zu halten. Daher verwende ich für Dateinamen in Vue die Groß-/Kleinschreibung, auch wenn ich mich darüber beschweren werde. Denn dem nicht zu folgen bedeutet, eine Menge Dateien zu ändern, die vue-cli einrichtet.
UPDATE 2021
An diesem Punkt in meinem Leben versuche ich, ausschließlich die kebab-case für Projektdateinamen.
Und eine seltsame Kombination aus snake_case.kebab-case.dot.case.Title.Case für Dateien, die für die menschliche Kommunikation bestimmt sind. Eine Excel-Datei, die einen Bericht enthält, könnte zum Beispiel sein "Report_Name-Report_Type-2021.05.04_13.02" für einen Bericht, der am 4. Mai um 13:02 Uhr erstellt wurde. Ich wollte eigentlich Title Case im Berichtsnamen, aber wenn Sie die Datei erneut speichern, erhalten Sie keine Leerzeichen. Und ich wollte eigentlich die Groß- und Kleinschreibung verwenden und den Datumsstempel isokonform machen, aber der Kunde war verwirrt, weil er das amerikanische Monat-Tag-Jahr-Format für Daten verwendet. Ein anderes Beispiel ist "SomeRequestForm-ProjectName-01.pdf" .
Client-lesbares Material ist schwer zu handhaben.
Ich vermeide Leerzeichen, wo immer es möglich ist (und der Kunde sie nicht verlangt), weil sie nicht cli-sicher sind. Ich habe den Angular-Ansatz für Dateinamen in Projekten übernommen. some-thing.type.ts , wobei die Beschreibung lautet kebab-case und der Standardtyp des in der Datei gespeicherten Objekts wird durch Punkte wie die Erweiterung getrennt. Ich mache normalerweise nicht some-area_some-thing.type.ts Es sei denn, die Datei ist eigenständig und portabel. Wenn sie in einem Projekt enthalten ist, verwende ich einfach Ordner wie some-area/some-thing.type.ts
Außerdem verwende ich kebab-case für css-Klassen, und ich mische manchmal snakeAndCamel_case für Html-Ids, aber normalerweise verwende ich keine Html-Ids mehr, weil ich mit wiederverwendbaren Komponenten arbeite, und das geht nicht. Wenn ich ids verwende, ist es typischerweise etwas wie someComponent-someElement_49bea6c9-551b-400a-a3e0-59ed40967646 wobei diese uuid eine generierte uuid ist, die von jeder Komponenteninstanz selbst vergeben wird. Dies ist nicht in Angular unterstützt, so dass ich neige dazu, mit anderen Workarounds zu kommen, wie halten die gesamte Formulareingabe innerhalb des Labels.
Außerdem verwende ich für Variablennamen immer noch hauptsächlich CamelCase, außer für Klassennamen und manchmal für Funktionsnamen. Wenn ich mit einem externen Paket arbeite, mache ich einfach das, was sie tun. Für Dinge, die Umgebungsvariablen imitieren, verwende ich ALL_CAPS_SNAKE_CASE Dies schließt node.js ein. process.env.SOME_ENV_VAR y combinedConfiguration.SOME_ENV_VAR (für den Fall, dass ich process.env mit einem Parameter config überschreibe)
Mein Fazit: Das gilt auch noch einige Jahre später. Es gibt keine einzig wahre Antwort. Aber versuchen Sie, einen Stil pro Projekt beizubehalten. Und reduzieren Sie die Anzahl der Wörter in Ihren Symbolen wo immer möglich.
