sonar css plugin

Sonarqube CSS / SCSS / weniger Analysator

Haftungsausschluss

Ich möchte dieses Plugin nicht weiterhin aufrechterhalten. Fühlen Sie sich frei, mich zu pingen, wenn Sie übernehmen möchten.

Beschreibung

Dieses Sonarqube -Plugin analysiert:

• CSS -Dateien
• CSS -Code in HTML/XHTML -Dateien eingebettet
• SCSS -Dateien
• Weniger Dateien

Und:

• Berechnet Metriken: Codezeilen, Komplexität, Anzahl der Regeln usw.
• Validiert Ihren CSS -Code
• Überprüfungen auf doppelten Code
• Überprüft verschiedene Richtlinien, um potenzielle Fehler, Schwachstellen und Code -Gerüche durch mehr als:
  • 80 Schecks auf den CSS -Code
  • 90 Schecks auf SCSS -Code
  • 80 Überprüfungen auf weniger Code
• Bietet die Möglichkeit, Ihre eigenen Schecks zu schreiben

Verwendung

Installationshandbuch

1. Laden Sie Sonarqube herunter und installieren Sie sie
2. Installieren Sie das CSS / SCSS / weniger Plugin durch einen direkten Download. Die neueste Version ist mit Sonarqube 6.7+ kompatibel.
3. Installieren Sie Ihren bevorzugten Scanner (Sonarqube -Scanner, Maven, Ant usw.)
4. Analysieren Sie Ihren Code

Analyse von CSS -Code in HTML/XHTML -Dateien eingebettet

Der Plugin analysiert den CSS -Code, der in <style type="text/css">...</style> Tags in HTML/XHTML -Dateien eingebettet ist. Als Voraussetzung muss Sonarqube diese Dateien importieren. Entweder:

• Installieren Sie ein Plugin, um diese Dateien importieren (beispielsweise Web -Plugin)
• Oder aktivieren Sie den Import unbekannter Dateien, indem Sie Eigenschaften sonar.import_unknown_files in true festlegen

Die Liste der Dateien, die eingebettete CSS enthalten, die zu analysieren sind, kann über die Eigenschaft sonar.css.embedded.file.suffixes angepasst werden.

Stylelint / Sonarqube -Regel Mapping

Wenn Sie bereits Stylelint verwenden, hilft Ihnen das Hinzufügen von Sonarqube zu Ihrem Stapel, dass Sie die Codequalität auf eine andere Ebene bringen. Die Stylelint / Sonarqube -Regel Mapping kann von großer Bedeutung sein, um Ihr Sonarqube -Qualitätsprofil zu definieren.

Benutzerdefinierte Schecks

Sie denken an neue wertvolle Schecks? Version 2.1 oder mehr bietet eine API, um Ihre eigenen benutzerdefinierten Schecks zu schreiben. Ein Beispiel -Plugin mit detaillierten Erklärungen finden Sie hier. Wenn Ihre benutzerdefinierten Überprüfungen der Community zugute kommen können, können Sie eine Pull -Anfrage erstellen, um den Scheck im CSS / SCSS / Less Analyzer verfügbar zu machen.

Sie denken an neue Schecks, die der Community zugute kommen können, aber nicht die Zeit oder die Fähigkeiten haben, sie zu schreiben? Fühlen Sie sich frei, ein Problem zu erstellen, damit Ihre Schecks berücksichtigt werden sollen.

Metriken

Funktionen

Anzahl der Regeln.

Komplexität

Die folgenden Elemente erhöhen die Komplexität um eins:

• Klassenauswahl
• ID -Selektor
• Attributauswahl
• Typ Selector
• Pseudo -Selektor
• Keyframes Selector
• AT-RULE

Komplexität/Funktion

Es berechnet die Komplexität/Regel, dh die durchschnittliche Anzahl der Selektoren pro Regel. Es gibt eine Messung darüber, wie spezifisch die Selektoren sind.

Verfügbare Regeln

Gemeinsam mit CSS und SCSS und weniger

• "! Wichtig" sollte am Ende der Erklärung platziert werden
• "! Wichtig" sollte nicht verwendet werden
• "@font-face" -Regel sollte mit den erforderlichen Browsern kompatibel gemacht werden
• "Fixme" -Tags sollten behandelt werden
• "Nosonar" -Tags sollten nicht verwendet werden, um Probleme auszuschalten
• "Stylelint-disable" -Tags sollten entfernt werden
• Tags "Stylelint-Enable" sollten entfernt werden
• Eigenschaften von "Text-Transformation" sollten nicht auf "Großbuchstaben" oder "Kapital" für einige Sprachen festgelegt werden
• "Todo" -Tags sollten gehandhabt werden
• @CharSet sollte das erste Element im Stylesheet sein und keinem Charakter vorausgehen
• Die Größe des Boxmodells sollte sorgfältig überprüft werden
• Byte Order Mark (BOM) sollte nicht für UTF-8-Dateien verwendet werden
• Fall-unempfindliches Flag sollte nicht verwendet werden
• Klassenauswahl sollten einer Namenskonvention folgen
• CSS sollte in niedrigerer Fall geschrieben werden
• Veraltete Systemfarben sollten nicht verwendet werden
• Doppelte Hintergrundbilder sollten entfernt werden
• Doppelte Eigenschaften sollten entfernt werden
• Jede Erklärung sollte mit einem Semikolon enden
• Leere Erklärungen sollten entfernt werden
• Leere Regeln sollten entfernt werden
• Leere Stylesheets sollten entfernt werden
• Experimentelle @-Rules sollte nicht verwendet werden
• Experimentelle Kennungen sollten nicht verwendet werden
• Versuchseigenschaften sollten nicht verwendet werden
• Experimentelle Pseudoelemente und Pseudoklassen sollten nicht verwendet werden
• Experimentelle Auswahlkombinatoren sollten nicht verwendet werden
• Dateien sollten am Ende eine leere neue Zeile enthalten
• Dateien sollten nicht zu viele Zeilen haben
• Schriftfamiliennamen sollten zitiert werden
• Schriftdateien, die in den Einbau sind, sollten nicht verwendet werden
• Schriftfamilieneigenschaften sollten mit einer generischen Schriftfamilie enden
• Die Schriftfamilie sollte keine doppelten Schriftart-Familiennamen enthalten
• Verbotene Eigenschaften sollten nicht verwendet werden
• Generische Schriftfamiliennamen sollten nicht zitiert werden
• Gradientendefinitionen sollten für alle Anbieter festgelegt werden
• ID -Selektoren sollten einer Namenskonvention folgen
• IDs in Selektoren sollten entfernt werden
• Führende Nullen sollten entfernt werden
• Linien sollten nicht zu lang sein
• Linien sollten nicht mit nachverfolgenden Weißespaces enden
• Fehlende Anbieter -Präfixe sollten zu experimentellen Eigenschaften hinzugefügt werden
• Der Name des überqualifizierten Elements sollte entfernt werden
• Die genannten Farben sollten nicht verwendet werden
• Die Zahlenpräzision sollte nicht zu hoch sein
• Obsolete Eigenschaften sollten nicht verwendet werden
• Obsolete Pseudo-Elemente und Pseudoklassen sollten nicht verwendet werden
• Obsolete Selektorkombinatoren sollten nicht verwendet werden
• Überspannte Selektoren sollten vereinfacht werden
• Eigenschaften, die nicht mit der Eigenschaft "Display" funktionieren, sollten entfernt werden
• Eigenschaftswerte sollten gültig sein
• Protokoll-relative URL sollte nicht verwendet werden
• Regelmäßiger Ausdruck wie Selektoren sollten nicht verwendet werden
• Regelmäßiger Ausdruck auf @-Rule
• Regelmäßiger Ausdruck zum Kommentar
• Regelmäßiger Ausdruck in der Funktion
• Regulärer Ausdruck auf dem Grundstück
• Regulärer Ausdruck auf Einheit
• Regeleigenschaften sollten alphabetisch geordnet werden
• Kurzeigenschaften sollten nach Möglichkeit verwendet werden
• Kurzeigenschaften sollten nicht verwendet werden
• Einzelzitate sollten anstelle von doppelten Zitaten für Zeichenfolgen verwendet werden
• Der Quellcode sollte den Formatierungsstandards entsprechen
• Standardeigenschaften sollten zusammen mit Lieferanten-vorgefertigten Eigenschaften angegeben werden
• Star Hack sollte nicht verwendet werden
• Stylesheets sollten nicht zu viele Regeln enthalten
• Stylesheets sollten nicht zu viele Selektoren enthalten
• Tabellierungszeichen sollten nicht verwendet werden
• Die Anzahl der Webschriften sollte reduziert werden
• Es sollte eine einzige Erklärung pro Linie geben
• Nachfolgende Nullen für numerische Werte sollten entfernt werden
• Typen in Selektoren sollten entfernt werden
• Unterstriche Hack sollte nicht verwendet werden
• Einheiten für Nulllängenwerte sollten entfernt werden
• Der universelle Selektor sollte nicht als Schlüsselteil verwendet werden
• Unbekannte @-Rules sollte entfernt werden
• Unbekannte Eigenschaften sollten entfernt werden
• Unbekannte Pseudoelemente und Pseudoklassen sollten entfernt werden
• Unbekannte Typ -Selektoren sollten entfernt werden
• URL 'Paper.gif' sollte niemals verwendet werden
• URL sollte zitiert werden

Spezifisch für CSS

• "@Import" -Regel sollte nicht verwendet werden
• @Import-Regeln sollten allen anderen Regeln und Stilregeln vorausgehen
• CSS -Variablen sollten einer Namenskonvention folgen
• Versuchsfunktionen sollten nicht verwendet werden
• Obsolete Funktionen sollten nicht verwendet werden
• Stylesheets sollten nicht zu viele andere Blätter "@import" "
• Unbekannte CSS -Funktionen sollten entfernt werden

Spezifisch für CSS in HTML/XHTML eingebettet

• CSS sollte nicht in HTML -Dateien eingebettet sein

Spezifisch für SCSS

• @Debug -Direktiven sollten nicht im Produktionscode verwendet werden
• @extend -Richtlinien sollten nicht verwendet werden
• @if ... @else Wenn ... Konstrukte mit @Else -Richtlinie enden sollten
• Verwenden Sie immer 'durch' anstelle von 'to' in @For Directives
• Bedingungen sollten nicht zu komplex sein
• Kontrollflussanweisungen @if, @else if, @else, @For, @when und @Each sollten nicht zu tief verschachtelt werden
• Benutzerdefinierte Funktionen sollten einer Namenskonvention folgen
• Erklärungen und Richtlinien sollten ordnungsgemäß sortiert werden
• Veraltete, nicht beschleunigte Multilin -Saiten sollten nicht verwendet werden
• Leere Steuerflussanweisung sollte entfernt werden
• Leere Mixins sollten entfernt werden
• Mixins sollten einer Namenskonvention folgen
• Verschachtelte Eigenschaften sollten mindestens zwei Eigenschaften definieren
• Die Platzhalterauswahl sollten einer Namenskonvention folgen
• Verwandte @if / @else Wenn Anweisungen nicht die gleiche Bedingung haben sollten
• Regeln sollten nicht zu tief verschachtelt werden
• SCSS -Variablen sollten einer Namenskonvention folgen
• Einzelzeilen-Kommentare (//) sollten gegenüber mehrkundigen Kommentaren (/ * ... */) bevorzugt werden
• Zwei Zweige in derselben bedingten Struktur sollten nicht genau die gleiche Implementierung aufweisen
• Nutzlose Klammern folgen @include und @Mixin ohne Parameter sollten entfernt werden

Spezifisch für weniger

• Die veraltete "E" -Floßfunktion sollte durch ~ "Wert" -Syntax ersetzt werden
• Weniger Variablen sollten einer Namenskonvention folgen
• Regeln sollten nicht zu tief verschachtelt werden
• Die gleiche Variable sollte nicht mehrmals im selben Bereich deklariert werden
• Einzelzeilen-Kommentare (//) sollten gegenüber mehrkundigen Kommentaren (/ * ... */) bevorzugt werden
• Unbekannte CSS / weniger Funktionen sollten entfernt werden
• Variablen sollten zu Beginn des Blocks deklariert werden