it-swarm.com.de

Ist es eine schlechte Praxis, einzelne Zeilen von // mit // zu kommentieren?

Ich habe vor kurzem mit // begonnen, um einzelne Zeilen des CSS-Codes zu "kommentieren". Ich verstehe, dass ich die Zeile eigentlich nicht auskommentiere; Ich breche es gerade (ich sollte /* ... */ verwenden), aber es hat den gleichen Effekt. Die Zeile wird dann durch den ; beendet und der folgende Code funktioniert einwandfrei.

Ich könnte es löschen, aber ich ziehe es oft vor, es nicht zu tun, falls ich es später wieder einsetzen möchte oder sehen würde, was ich gebraucht habe, wenn ich darauf zurückkomme.

Beispiel:

li{
    float:left;
    //list-style-type:none;
    text-indent:0px;
}

Kann ich damit durchkommen, oder macht es mir wahrscheinlich Probleme?

58
Adam Milward

In erster Linie: Auskommentierter Code ist ein -Code-Geruch und sollte vermieden werden. Ich gehe davon aus, dass Sie ein VCS wie Git verwenden, das historischen Code für Sie verarbeitet.

Wenn Sie jedoch wirklich so arbeiten möchten: Sie wissen nicht, wie zukünftige und/oder exotische Browser nicht offizielle Hacks wie // interpretieren werden.

li {
    float:left;
    text-indent:0px;
    /* list-style-type:none; */
}
43
Dennis Traub

Ich sehe, dass es viele Leute gab/gibt, die sich darüber beschwerten, und da dies eine ältere Frage ist, fragen sich wahrscheinlich viele Leute, ob es immer noch wahr ist oder ob es überhaupt einen Standard gibt. Erlaube mir die Luft zu klären. Im Folgenden sind die Hauptgründe für die strenge CSS-Kommentarrichtlinie aufgeführt:

# 1 Es ist kein Standard

Mindestens seit CSS 2.1 standardisiert, dürfen Kommentare NUR in /* und */ eingeschlossen werden. Während einige Browser // tolerieren, sollten sie das nicht und sind nur einen Zentimeter von jemandem entfernt, der sagt "oh ja, das ist nicht Standard" oder "hey! Das ist nicht Standard, behebe es!"; und dann raten Sie mal, was Ihr CSS-Code, der funktioniert hat, jetzt nicht mehr für Tausende von Menschen (und möglicherweise schon für Hunderte von anderen). Ich werde hinzufügen, dass <!-- und --> nur dann zulässig sind (und ich meine NUR), wenn sie in einem HTML-Dokument und nicht in einer CSS-Quelldatei enthalten sind. Wenn Ihr Browser so alt ist, dass er <style> Tags nicht überspringen kann, ist es wahrscheinlich Zeit für einen neuen Browser vor 10 Jahren. Sogar Lynx und andere Textbrowser wissen, dass sie nicht gelesen werden. Das Auskommentieren ist daher nur in sehr isolierten Situationen sinnvoll, in denen Hardware und Software in ihrem aktuellen Arbeitszustand blockiert sind.

# 2 Es ist nicht (sehr) plattformübergreifend

Der einzeilige Kommentar, der an einer beliebigen Stelle in einer Zeile mit // beginnt, wird mit 'newline' abgeschlossen, bei dem es sich nicht um plattformübergreifend standardisierte Zeichen handelt. Schlimmer noch, einige haben möglicherweise ein Zeichen für eine neue Zeile oder 2 ... und wenn sich diese Plattformen vermischen, kann eine neue Zeile verloren gehen, und da ist Ihr Terminator ... und Ihr Code wird jetzt teilweise oder vollständig auskommentiert sollte nicht sein, man muss kein Genie sein, um zu wissen, was die Konsequenzen davon sein könnten, insbesondere wenn Sie die Funktionen Ihrer Website ausschließlich über CSS steuern, was viele tun.

# 3 Der Standard IS Freundlich und für alle einheitlich

Die Begrenzer /* und */ sind IMMER die gleichen Zeichen auf JEDEM Computer, unabhängig von Architektur, Betriebssystem usw.

# 4 Newlines sind Whitespaces

Der letzte Grund (ja, es gibt noch einen), Newline-Zeichen gelten (in CSS und vielen anderen Sprachen) als Leerzeichen, und */ ist kein Leerzeichen, oder? Und wenn Sie an dieser Stelle darüber nachdenken, sollte klar sein, dass Sie KEINE Leerzeichen zum Beenden eines Kommentars verwenden sollten, zumal Leerzeichen von vielen HTML/CSS-Parsern entfernt oder neu formatiert werden können, ohne dass Sie davon etwas wissen.

# 5 CSS! = C/C++

Wenn Sie jetzt aus Ihrem Sitz fliegen und mich wegen "Hey, but C++ ..." anschreien möchten, denken Sie daran, dass in diesen Compilern und IDEs jede Menge Newline-Prüfungen und -Erkennungen eingebaut sind, damit sie diese übernehmen können. Die meisten Compiler formatieren Ihren Code nur nach Aufforderung neu, und in vielen IDEs werden Sie normalerweise gefragt, welche Art von Zeilenumbrüchen Ihr Dokument verwendet, wenn es nicht selbst raten kann. Wenn wir dies mit CSS-Seiten für den Endbenutzer jedes Mal tun würden, wenn eine geladen wird, stellen Sie sich den Albtraum vor, den es zu umgehen versuchen würde. Darüber hinaus wird C/C++ - Code zur Laufzeit nicht analysiert und kompiliert, sodass der Benutzer das betreffende Dokument in den meisten Fällen überhaupt nicht erhält. Die Quelldateien werden nicht ständig von der ganzen Welt auf Hunderten von Plattformen und vielen Betriebssystemen sowie einer Million verschiedener Browser angezeigt. Die Kommentare werden entfernt, bevor sie an den Endbenutzer gelangen. Die CSS-Quelle kommt direkt zum Browser des Benutzers und muss sehr belastbar sein, ohne zu wissen, was sich auf der anderen Seite befindet. Daher muss sie für alles bereit sein, was der Endbenutzer hat oder tut, nicht für alles, was der Entwickler tut oder hat!

# 6 Es ist unpraktisch

Nein, es ist sehr ärgerlich, diesen zusätzlichen */ eingeben zu müssen, aber die Schuld dafür liegt hauptsächlich bei Entwicklern von CSS-Bearbeitungssoftware, die keine automatische Vervollständigung anbieten. Wenn Sie einen spezialisierten Editor verwenden, der dies möglichst sofort erledigt, ist dies genauso einfach wie die Verwendung von //. Machen Sie es sich zur Gewohnheit, /**/ und dann die Rücktaste 2 einzugeben, damit Sie nichts vergessen und es ein wenig einfacher machen. Besser noch, Sie können einen Tastenkürzel einrichten, um diese einfach für Sie festzulegen. Windows und Linux haben leistungsstarke Tools, um dies zu ermöglichen (KDE ist dafür sehr gut geeignet).


Ich hoffe, dies hilft jedem, das "Warum" hinter dem "Wie" zu verstehen und sich daran zu erinnern, dass etwas für Sie funktioniert, was nicht bedeutet, dass es der Standard ist, und um es zusammenzufassen:

JA, ES IS SCHLECHTE PRAXIS, es zu benutzen, sag einfach NEIN zu dem doppelten Schrägstrich !!! Wenn du eine visuelle Hilfe brauchst Um Sie an diese wichtige Tatsache zu erinnern, brennen Sie sich einfach dieses Bild in den Kopf (danke an diejenigen von Ihnen, die nichts Besseres zu tun haben, als Bilder wie dieses zu machen):

No double slash


PS: Wenn Sie sich wirklich über die beschweren möchten, die CSS-Standards (W3C, Elbow) erstellen oder brechen, beginnt jemand eine Diskussion darüber, wie unnötig lang und falsch das Schlüsselwort "! Important" ist! Aber das ist nicht Teil dieser Frage, deshalb werde ich nicht darauf eingehen.

Verweise

  • W3C : CSS 2.1-Arbeitsentwurf: Kommentarzeichen.
  • W3C : CSS-Syntaxmodul Level 3: Eisenbahndiagramme von Parser-zu-Zeichen-Interpretationen.
  • Stapelüberlauf : Verschiedene Stapelüberlaufartikel mit praktisch demselben Thema wie dieses.
  • w3schools : CSS 3-Syntaxstandard (der wiederum auf W3C verweist).
  • sitepoint : CSS-Syntaxanmerkung für "ohne doppelten Schrägstrich".
  • mozilla | mdn : Die entspannte CSS 3-Verarbeitung ermöglicht doppelte Schrägstriche in Eingabedateien.
75
osirisgothra

Ich habe kürzlich diesen Artikel gelesen, der viel Einsicht in die einzeilige Kommentierpraxis in CSS gibt.

CSS erlaubt die Verwendung von // nach einer Mode. Es ist kein Zeilenkommentar, sondern ein nächster Konstruktkommentar. Das heißt, wenn Sie // verwenden, wird das nächste CSS-Konstrukt - entweder Deklaration oder Block - "auskommentiert".

In Ihrem Code-Snippet ist list-style-type:none das nächste CSS-Konstrukt und es wird auskommentiert.

li {
    float:left;
    //list-style-type:none;
    text-indent:0px;
}

Ähnlich im folgenden Code-Snippet

//@keyframes foo {
  from, to { width: 500px; }
  50% { width: 400px; }
}
@keyframes bar {
  from, to { height: 500px; }
  50% { height: 400px; }
}

der // kommentiert die erste @keyframes-Deklaration aus.

Wenn Sie versuchen, // nur für das Schreiben von Kommentaren in Ihr Stylesheet zu verwenden, müssen Sie vorsichtig sein. Rohtext ist kein CSS-Konstrukt. Er wird also darüber hinausschauen und das nächste Konstrukt auf Ihrer Seite auskommentieren. Also im folgenden Ausschnitt

// Do some stuff.
.foo { animation: bar 1s infinite; }

Dadurch wird der .foo-Block auskommentiert.

Weitere Informationen erhalten Sie über den eingangs genannten verlinkten Artikel.

5
Naveen

Laut dem Working Draft gibt es nichts wie einen einzeiligen Kommentar.

4
Rob

Ja, ich denke, dass die Verwendung von einzeiligen Kommentaren im aktuellen Zustand schlechte Praxis ist.

Wenn Sie in einer Teamumgebung arbeiten, ist die Wartbarkeit/Lesbarkeit von Code von größter Bedeutung. Selbst wenn Sie alleine arbeiten, ist das Schreiben von wartungsfähigem Code immer noch eine gute Praxis. Andernfalls wird Wahnsinn entstehen.

Wenn Sie anfangen, einzeilige Kommentare zu verwenden, werden sowohl die Wartbarkeit als auch die Lesbarkeit beeinträchtigt. Syntax-Hervorhebungen in Editoren heben Ihren Kommentar nicht hervor und es wird schwierig, Kommentare von Regeln zu unterscheiden.

Comparison of single and multi-line comments

Außerdem sind einzeilige und mehrzeilige Kommentare nicht inklusiv austauschbar. Sie können beispielsweise keine Rohtextkommentare ohne Hack verwenden, sondern nur die Konstrukte //.foo {...} oder Regeln .foo {//height:10px} auskommentieren.

Nicht austauschbare Instanz:

ul.images {
    padding: 0;
    //static height value
    height: 270px;
    margin: 0 auto;
}
ul.images {
    padding: 0;
    /*static height value
    height: 270px;*/
    margin: 0 auto;
}

Jetzt austauschbar (wegen leerem Konstruktor hack):

ul.images {
    padding: 0;
    //static height value{};
    height: 270px;
    margin: 0 auto;
}
ul.images {
    padding: 0;
    /*static height value*/
    height: 270px;
    margin: 0 auto;
}

Die Verwendung des Konstruktors {}; als Postfix funktioniert zwar, IMO kann jedoch nicht verwendet werden, da Sie more -Zeichen verwenden. Ein mehrzeiliger Kommentar verwendet vier Zeichen, /**/, während ein einzeiliger Kommentar mit dem Hack fünf Zeichen enthält, //{};

Der letzte Nachteil von einzeiligen Kommentaren, der noch nicht erwähnt wurde, ist, dass Chrome Developer Tools auskommentierte Regeln ausblenden, anstatt dass Sie sie umschalten können.

Chrome-Entwicklerwerkzeuge (mehrzeiliger Kommentar):

Enter image description here

Chrome-Entwicklerwerkzeuge (einzeiliger Kommentar):

Enter image description here

Ein guter Anwendungsfall, IMO, für einzeilige Kommentare wäre, wenn Sie einen ganzen Konstruktor auskommentieren müssen, was sehr lang ist (das Beispiel ist nicht der Fall).

Einen ganzen Konstruktor auskommentieren

//ul.images {
    padding: 0;
    height: 270px;
    margin: 0 auto;
}

/*ul.images {
    padding: 0;
    height: 270px;
    margin: 0 auto;
}*/

Wenn Sie versuchen, während der Entwicklung etwas zu debuggen, sehe ich nicht den Nachteil, wenn Sie einen Konstruktor mit einzeiligen Kommentaren auskommentieren, um einen Fehler auszusondern. Wenn Sie debuggen, ist es vorübergehend. Das heißt, ich sehe keinen Anwendungsfall für Rohtext, daher würde ich mich definitiv nicht dafür einsetzen, sie dort zu verwenden.

3
Jack Tuck

Ich würde empfehlen, CSS nicht so zu kommentieren, wenn es nicht benötigt wird. Entfernen Sie das, was Sie nicht brauchen, und übergeben Sie es Ihrem SVN- oder GIT-Repository. Lassen Sie es seine Arbeit machen und verfolgen Sie die Geschichte für Sie. Akkumulierte Kommentare wie diese werden zu Krüppel, die Ihren Code schwerer lesen und verstehen lassen.

2
duffymo

Ich benutze //, um Zeilen in .css-Dateien ständig auszukommentieren. Weil es an eine Verknüpfung in Vim gebunden ist und ich immer vergesse, was ich bearbeite. In JavaScript ist es sehr praktisch, Codeblöcke auszukommentieren, den Code zu testen und den Codeblock erneut zu "kommentieren" (Tastenkombinationen, ja).

Wenn ich meine .css-Datei aufgeräumt habe, verwende ich die folgenden Konstrukte, um Deklarationen leichter in den und aus dem Gültigkeitsbereich zu verschieben:

.pin {
    /*
    position: absolute;
    background: url(buttons-3x3.png);
    background-color: red;
    */
    height:50px;
    width:150px;
    position: relative;
}


.shadow {
    margin-top: 25px;
    margin-left: 25px;
    margin-left: 60px;
    width:50px;
    height:50px;
    background: url(playground.png) -400px -100px;
    position: relative;
    position: absolute;
}

In .pin kann ich eine Zeile entfernen und sie dem kommentierten Bereich hinzufügen und umgekehrt. In .shadow deklariere ich einfach die gleiche Eigenschaft mit einem anderen Wert.

Es ist ätzend.

! wichtig

2
user37057

Wie andere bereits gesagt haben, ist die Verwendung eines doppelten Schrägstrichs nicht standardkonform, aber wenn Sie wirklich verwenden wollen UND standardkonform sein wollen UND GCC installiert haben, können Sie Ihr CSS über cpp -P ausführen, um alle doppelten Werte zu entfernen Schrägstrich und/* ... */Kommentare aus dem CSS. Als Bonus können Sie Makros, Includes und Bedingungen verwenden, und Kommentare werden nicht vom Browser heruntergeladen (geringfügiger Leistungsschub). 

Das einzige große Problem ist die Verwendung von eigenständigen ID-Tags (d. H. #para { ... }), wobei cpp barfs. Lösung ist das doppelte # (zu ##) und durchläuft die Ausgabe wie folgt:

cpp -P site.cssin | sed -e 's/^##/#/' >site.css

Ich bin sicher, es gibt bessere CSS-orientierte Vorprozessoren, aber das hat für mich funktioniert.

1
AndrewTPhoto

Für Inline-CSS-Kommentare verwende ich:

.myDiv {
    @width:750px;  
}

oder ein beliebiges Zeichen (d. h. *@!ZZ) Die Eigenschaft wird also unbekannt und kann von css nicht gelesen werden.

1
T.Todua

Kommentar in HTML:

<!--........................-->
<!--  <input type="text" name="lastname">-->

Kommentar in JavaScript:

Einzeiliger Kommentar:

Zwei Schrägstriche "//" vor dem Code:

//document.write("Try this");

Mehrzeiliger Kommentar:

<script type="text/javascript">
    <!--

    /* document.write("try this!");

    document.write("try this"); */
    //-->

</script>

Kommentarcode in CSS:

/*
.tblemp {
color:red; }

*/

Mehr Details

0
Tamilan

Fügen Sie einfach weitere Informationen hinzu und bestätigen Sie die Regel "Nur Verwendung/* Kommentare". Ein Kunde, der Zugriff auf den Websiteordner hat, wählt einfach selbst aus, um eine Zeile mit folgendem Kommentar zu kommentieren:

//*  comment here   *//

Eigentlich wird Chrome und Safari ALLES ignorieren, das auf diese Zeile folgt. Ich würde es "CSS-Killer" nennen.

0
Dario Corno