sonar css plugin

Sonarqube CSS / SCSS / Less Analyzer

คำเตือน

ฉันไม่ต้องการดูแลปลั๊กอินนี้ต่อไป อย่าลังเลที่จะ ping ฉันถ้าคุณต้องการที่จะครอบครอง

คำอธิบาย

ปลั๊กอิน Sonarqube นี้วิเคราะห์:

• ไฟล์ CSS
• รหัส CSS ที่ฝังอยู่ในไฟล์ HTML/XHTML
• ไฟล์ SCSS
• ไฟล์น้อยลง

และ:

• คำนวณตัวชี้วัด: บรรทัดของรหัสความซับซ้อนจำนวนกฎ ฯลฯ
• ตรวจสอบรหัส CSS ของคุณ
• ตรวจสอบรหัสที่ซ้ำกัน
• ตรวจสอบแนวทางต่าง ๆ เพื่อค้นหาข้อบกพร่องที่อาจเกิดขึ้นช่องโหว่และรหัสได้กลิ่นมากกว่า:
  • 80 ตรวจสอบรหัส CSS
  • 90 ตรวจสอบรหัส SCSS
  • 80 ตรวจสอบรหัสน้อย
• ให้ความสามารถในการเขียนเช็คของคุณเอง

การใช้งาน

คู่มือการติดตั้ง

1. ดาวน์โหลดและติดตั้ง sonarqube
2. ติดตั้ง CSS / SCSS / ปลั๊กอินน้อยลงด้วยการดาวน์โหลดโดยตรง เวอร์ชันล่าสุดเข้ากันได้กับ Sonarqube 6.7+
3. ติดตั้งเครื่องสแกนที่คุณชื่นชอบ (Sonarqube Scanner, Maven, Ant, ฯลฯ )
4. วิเคราะห์รหัสของคุณ

การวิเคราะห์รหัส CSS ที่ฝังอยู่ในไฟล์ HTML/XHTML

ปลั๊กอินวิเคราะห์รหัส CSS ที่ฝังอยู่ใน <style type="text/css">...</style> แท็กในไฟล์ HTML/XHTML ในการทำเช่นนั้นตามข้อกำหนดเบื้องต้น Sonarqube ต้องนำเข้าไฟล์เหล่านั้น ทั้ง:

• ติดตั้งปลั๊กอินที่นำเข้าไฟล์เหล่านั้น (ตัวอย่างเช่นปลั๊กอินเว็บ)
• หรือเปิดการนำเข้าไฟล์ที่ไม่รู้จักโดยการตั้งค่าคุณสมบัติ sonar.import_unknown_files เป็น true

รายการไฟล์ที่มี CSS ฝังอยู่ในการวิเคราะห์สามารถปรับแต่งได้ผ่านคุณสมบัติ sonar.css.embedded.file.suffixes

การทำแผนที่กฎ Stylelint / Sonarqube

หากคุณใช้ Stylelint แล้วการเพิ่ม Sonarqube ลงในสแต็กของคุณจะช่วยให้คุณนำคุณภาพของรหัสไปสู่อีกระดับหนึ่ง การทำแผนที่กฎ Stylelint / Sonarqube อาจช่วยได้อย่างดีในการกำหนดโปรไฟล์คุณภาพ Sonarqube ของคุณ

การตรวจสอบที่กำหนดเอง

คุณกำลังคิดถึงการตรวจสอบที่มีค่าใหม่หรือไม่? เวอร์ชัน 2.1 หรือมากกว่ามี API เพื่อเขียนเช็คที่กำหนดเองของคุณเอง ปลั๊กอินตัวอย่างพร้อมคำอธิบายโดยละเอียดมีอยู่ที่นี่ หากการตรวจสอบที่กำหนดเองของคุณอาจเป็นประโยชน์ต่อชุมชนอย่าลังเลที่จะสร้างคำขอดึงเพื่อให้ตรวจสอบใน CSS / SCSS / Less Analyzer

คุณกำลังคิดถึงการตรวจสอบใหม่ที่อาจเป็นประโยชน์ต่อชุมชน แต่ไม่มีเวลาหรือทักษะในการเขียน? อย่าลังเลที่จะสร้างปัญหาสำหรับการตรวจสอบของคุณที่จะพิจารณา

ตัวชี้วัด

ฟังก์ชั่น

จำนวนกฎ

ความซับซ้อน

องค์ประกอบต่อไปนี้เพิ่มความซับซ้อนโดยหนึ่ง:

• ตัวเลือกชั้นเรียน
• ตัวเลือก id
• ตัวเลือกแอตทริบิวต์
• ประเภทตัวเลือก
• ตัวเลือกเทียม
• ตัวเลือก keyframes
• การปกครอง

ความซับซ้อน/ฟังก์ชั่น

มันคำนวณความซับซ้อน/กฎหมายถึงจำนวนตัวเลือกเฉลี่ยต่อกฎ มันให้การวัดว่าตัวเลือกเฉพาะเจาะจงเป็นอย่างไร

กฎที่มีอยู่

ร่วมกันกับ CSS และ SCSS และน้อยกว่า

• ควรวางธง "สำคัญ" เมื่อสิ้นสุดการประกาศ
• ไม่ควรใช้ธง "สำคัญ"
• กฎ "@font-face" ควรทำให้เข้ากันได้กับเบราว์เซอร์ที่ต้องการ
• ควรจัดการแท็ก "fixme"
• ไม่ควรใช้แท็ก "Nosonar" เพื่อปิดปัญหา
• ควรลบแท็ก "stylelint-disable"
• ควรลบแท็ก "stylelint-enable"
• คุณสมบัติ "text-transform" ไม่ควรตั้งค่าเป็น "ตัวพิมพ์ใหญ่" หรือ "ใช้ประโยชน์" สำหรับบางภาษา
• ควรจัดการแท็ก "todo"
• @Charset ควรเป็นองค์ประกอบแรกในแผ่นสไตล์และไม่นำหน้าด้วยตัวละครใด ๆ
• ขนาดของโมเดลกล่องควรได้รับการตรวจสอบอย่างรอบคอบ
• ไม่ควรใช้เครื่องหมายคำสั่งซื้อไบต์ (BOM) สำหรับไฟล์ UTF-8
• ไม่ควรใช้ธงที่ไม่รู้สึกตัว
• ตัวเลือกคลาสควรทำตามอนุสัญญาการตั้งชื่อ
• ควรเขียน CSS เป็นตัวพิมพ์เล็ก
• ไม่ควรใช้สีของระบบที่เลิกใช้
• ควรลบภาพพื้นหลังที่ซ้ำกัน
• ควรลบคุณสมบัติที่ซ้ำกัน
• การประกาศแต่ละครั้งควรจบลงด้วยเครื่องหมายอัฒภาค
• ควรลบประกาศที่ว่างเปล่า
• ควรลบกฎว่างเปล่า
• ควรลบสไตล์ชีทที่ว่างเปล่า
• ไม่ควรใช้การทดลอง @-rules
• ไม่ควรใช้ตัวระบุการทดลอง
• ไม่ควรใช้คุณสมบัติการทดลอง
• ไม่ควรใช้องค์ประกอบหลอกและคลาสหลอก
• ไม่ควรใช้ตัวเลือกการทดลอง
• ไฟล์ควรมีบรรทัดใหม่ที่ว่างเปล่าในตอนท้าย
• ไฟล์ไม่ควรมีบรรทัดมากเกินไป
• ควรอ้างชื่อครอบครัวแบบอักษร
• ไม่ควรใช้ไฟล์แบบอักษร
• คุณสมบัติของครอบครัวแบบครอบครัวควรจบลงด้วยตระกูลฟอนต์ทั่วไป
• Font-Family ไม่ควรมีชื่อตระกูล Font ที่ซ้ำกัน
• ไม่ควรใช้คุณสมบัติต้องห้าม
• ไม่ควรอ้างชื่อครอบครัวแบบอักษรทั่วไป
• คำจำกัดความการไล่ระดับสีควรตั้งค่าสำหรับผู้ขายทั้งหมด
• ตัวเลือก ID ควรทำตามอนุสัญญาการตั้งชื่อ
• ควรลบรหัสในตัวเลือก
• ศูนย์ชั้นนำควรถูกลบออก
• เส้นไม่ควรยาวเกินไป
• เส้นไม่ควรจบลงด้วยช่องว่าง
• ควรเพิ่มคำนำหน้าผู้ขายที่ขาดหายไปในคุณสมบัติการทดลอง
• ควรลบชื่อขององค์ประกอบที่มีคุณสมบัติมากเกินไป
• ไม่ควรใช้สีที่มีชื่อ
• ความแม่นยำจำนวนไม่ควรสูงเกินไป
• ไม่ควรใช้คุณสมบัติล้าสมัย
• ไม่ควรใช้องค์ประกอบหลอกและคลาสหลอก
• ไม่ควรใช้ตัวเลือกที่ล้าสมัย
• ตัวเลือกที่ระบุมากเกินไปควรทำให้ง่ายขึ้น
• คุณสมบัติที่ไม่สามารถใช้งานได้กับคุณสมบัติ "แสดง"
• ค่าคุณสมบัติควรใช้ได้
• ไม่ควรใช้ URL ที่เกี่ยวข้องกับโปรโตคอล
• ไม่ควรใช้นิพจน์ทั่วไปเช่นตัวเลือก
• นิพจน์ทั่วไปบน @-rule
• นิพจน์ทั่วไปเกี่ยวกับความคิดเห็น
• นิพจน์ทั่วไปเกี่ยวกับฟังก์ชั่น
• การแสดงออกปกติเกี่ยวกับคุณสมบัติ
• นิพจน์ทั่วไปในหน่วย
• คุณสมบัติของกฎควรได้รับการสั่งซื้อตามตัวอักษร
• ควรใช้คุณสมบัติชวเลขทุกครั้งที่ทำได้
• ไม่ควรใช้คุณสมบัติชวเลข
• ควรใช้คำพูดเดียวแทนคำพูดสองเท่าสำหรับสตริง
• ซอร์สโค้ดควรปฏิบัติตามมาตรฐานการจัดรูปแบบ
• ควรระบุคุณสมบัติมาตรฐานพร้อมกับคุณสมบัติที่กำหนดโดยผู้ขาย
• ไม่ควรใช้แฮ็คดาว
• สไตล์ชีทไม่ควรมีกฎมากเกินไป
• สไตล์ชีทไม่ควรมีตัวเลือกมากเกินไป
• ไม่ควรใช้อักขระตาราง
• จำนวนฟอนต์เว็บควรลดลง
• ควรมีการประกาศครั้งเดียวต่อบรรทัดเดียว
• ศูนย์ต่อท้ายสำหรับค่าตัวเลขควรถูกลบออก
• ควรลบประเภทในตัวเลือก
• ไม่ควรใช้แฮ็ค
• ควรลบหน่วยสำหรับค่าความยาวศูนย์
• ไม่ควรใช้ตัวเลือกสากลเป็นส่วนสำคัญ
• ไม่ทราบ @-rules ควรถูกลบออก
• คุณสมบัติที่ไม่รู้จักควรถูกลบออก
• ควรลบองค์ประกอบหลอกและคลาสหลอกควรถูกลบออก
• ควรลบตัวเลือกประเภทที่ไม่รู้จัก
• ไม่ควรใช้ url 'paper.gif'
• ควรมีการเสนอราคา URL

เฉพาะสำหรับ CSS

• ไม่ควรใช้กฎ "@Import"
• กฎ @Import ควรนำหน้ากฎอื่น ๆ และกฎสไตล์อื่น ๆ ทั้งหมด
• ตัวแปร CSS ควรทำตามอนุสัญญาการตั้งชื่อ
• ไม่ควรใช้ฟังก์ชั่นการทดลอง
• ไม่ควรใช้ฟังก์ชั่นล้าสมัย
• Stylesheets ไม่ควร "@Import" แผ่นอื่น ๆ มากเกินไป
• ควรลบฟังก์ชั่น CSS ที่ไม่รู้จัก

เฉพาะสำหรับ CSS ที่ฝังอยู่ใน HTML/XHTML

• CSS ไม่ควรฝังในไฟล์ HTML

เฉพาะสำหรับ SCSS

• ไม่ควรใช้คำสั่ง @debug ในรหัสการผลิต
• ไม่ควรใช้คำสั่ง @extend
• @if ... @else ถ้า ... การสร้างควรจบลงด้วย @else Directive
• ใช้ 'ผ่าน' แทนที่จะเป็น 'ถึง' ใน @สำหรับคำสั่ง
• เงื่อนไขไม่ควรซับซ้อนเกินไป
• คำสั่งการควบคุมโฟลว์ @if, @else if, @else, @for, @ในขณะที่และ @each ไม่ควรซ้อนกันมากเกินไป
• ฟังก์ชั่นที่กำหนดเองควรเป็นไปตามอนุสัญญาการตั้งชื่อ
• การประกาศและคำสั่งควรจัดเรียงอย่างถูกต้อง
• ไม่ควรใช้สตริงหลายสายที่ยังไม่ได้รับการคัดเลือก
• ควรลบคำสั่งการควบคุมการควบคุมที่ว่างเปล่า
• ควรลบส่วนผสมที่ว่างเปล่า
• Mixins ควรทำตามอนุสัญญาการตั้งชื่อ
• คุณสมบัติที่ซ้อนกันควรกำหนดคุณสมบัติอย่างน้อยสองคุณสมบัติ
• ตัวเลือกตัวยึดตำแหน่งควรทำตามอนุสัญญาการตั้งชื่อ
• @if ที่เกี่ยวข้อง / @else หากคำสั่งไม่ควรมีเงื่อนไขเดียวกัน
• ชุดกฎไม่ควรซ้อนกันมากเกินไป
• ตัวแปร SCSS ควรทำตามอนุสัญญาการตั้งชื่อ
• ความคิดเห็นบรรทัดเดียว (//) ควรเป็นที่ต้องการมากกว่าความคิดเห็นแบบหลายบรรทัด (/ * ... */)
• สองสาขาในโครงสร้างเงื่อนไขเดียวกันไม่ควรมีการใช้งานเดียวกันอย่างแน่นอน
• วงเล็บไร้ประโยชน์ต่อไปนี้ @include และ @mixin โดยไม่ควรลบพารามิเตอร์

เฉพาะเจาะจง

• ฟังก์ชั่น "E" ที่เลิกใช้แล้วควรถูกแทนที่ด้วยไวยากรณ์ ~ "value"
• ตัวแปรน้อยควรทำตามอนุสัญญาการตั้งชื่อ
• ชุดกฎไม่ควรซ้อนกันมากเกินไป
• ไม่ควรประกาศตัวแปรเดียวกันหลายครั้งภายในขอบเขตเดียวกัน
• ความคิดเห็นบรรทัดเดียว (//) ควรเป็นที่ต้องการมากกว่าความคิดเห็นแบบหลายบรรทัด (/ * ... */)
• ไม่ทราบ CSS / ฟังก์ชั่นที่น้อยกว่าควรถูกลบออก
• ควรประกาศตัวแปรที่จุดเริ่มต้นของบล็อก