SONARQUBE CSS / SCSS / LESS Analisador
Isenção de responsabilidade
Não quero continuar mantendo este plug -in. Sinta -se à vontade para me pingar se quiser assumir o controle.
Descrição
Este plug -in Sonarqube analisa:
- Arquivos CSS
- Código CSS incorporado em arquivos html/xhtml
- Arquivos SCSS
- Menos arquivos
e:
- Calcula métricas: linhas de código, complexidade, número de regras, etc.
- Valida seu código CSS
- Verifica o código duplicado
- Verifica várias diretrizes para descobrir possíveis insetos, vulnerabilidades e código cheira a mais de:
- 80 cheques no código CSS
- 90 verificações no código SCSS
- 80 cheques em menos código
- Fornece a capacidade de escrever seus próprios cheques
Uso
Guia de instalação
- Baixar e instalar Sonarqube
- Instale o plug -in CSS / SCSS / LESS por um download direto. A versão mais recente é compatível com o Sonarqube 6.7+.
- Instale seu scanner favorito (Sonarqube Scanner, Maven, Ant, etc.)
- Analise seu código
Analisando o código CSS incorporado em arquivos html/xhtml
O plug -in analisa o código CSS incorporado em tags <style type="text/css">...</style> em arquivos html/xhtml. Para fazer isso, como pré -requisito, o Sonarqube precisa importar esses arquivos. Qualquer:
- Instale um plug -in importando esses arquivos (plug -in da web, por exemplo)
- Ou ativar a importação de arquivos desconhecidos definindo a propriedade
sonar.import_unknown_files para true
A lista de arquivos que contêm CSs incorporados a serem analisados pode ser personalizada através da propriedade sonar.css.embedded.file.suffixes .
Mapeamento de regras de Stylelint / Sonarqube
Se você já está usando o Stylelint, adicionar Sonarqube à sua pilha ajudará você a trazer a qualidade do código para outro nível. O mapeamento de regras Stylelint / Sonarqube pode ser de grande ajuda para definir seu perfil de qualidade do sonarqube.
Verificações personalizadas
Você está pensando em novos cheques valiosos? A versão 2.1 ou superior fornece uma API para escrever suas próprias verificações personalizadas. Um plug -in de amostra com explicações detalhadas está disponível aqui. Se suas verificações personalizadas podem beneficiar a comunidade, sinta -se à vontade para criar uma solicitação de tração para disponibilizar o cheque no CSS / SCSS / menos analisador.
Você está pensando em novos cheques que podem beneficiar a comunidade, mas não têm tempo ou habilidades para escrevê -los? Sinta -se à vontade para criar um problema para que seus cheques sejam levados em consideração.
Métricas
Funções
Número de regras.
Complexidade
Os seguintes elementos aumentam a complexidade por um:
- Seletor de classe
- Seletor de identificação
- Seletor de atributo
- Seletor de tipo
- Seletor de pseudo
- Seletor de quadros -chave
- AT-RULE
Complexidade/função
Ele calcula a complexidade/regra, o que significa o número médio de seletores por regra. Ele fornece uma medida sobre quão específicos os seletores são.
Regras disponíveis
Comum ao CSS e SCSS e menos
- A bandeira "!! IMPORTANTE" deve ser colocada no final da declaração
- A bandeira "!! IMPORTANTE" não deve ser usada
- A regra "@font-face" deve ser compatível com os navegadores necessários
- As tags "Fixme" devem ser tratadas
- As tags "Nosonar" não devem ser usadas para desligar os problemas
- As tags "Stylelint-Disisable" devem ser removidas
- As tags de "habilitação de stylelint" devem ser removidas
- As propriedades de "transformação de texto" não devem ser definidas como "maiúsculas" ou "capitalizadas" para alguns idiomas
- Tags "TODO" devem ser tratadas
- @charset deve ser o primeiro elemento na folha de estilo e não ser precedido por qualquer personagem
- O tamanho do modelo da caixa deve ser cuidadosamente revisado
- Marca de pedidos de byte (BOM) não deve ser usada para arquivos UTF-8
- Bandeira insensível ao caso não deve ser usada
- Seletores de classe devem seguir uma convenção de nomenclatura
- CSS deve ser escrito em minúsculas
- As cores descontinuadas do sistema não devem ser usadas
- Imagens de fundo duplicadas devem ser removidas
- Propriedades duplicadas devem ser removidas
- Cada declaração deve terminar com um semicolon
- Declarações vazias devem ser removidas
- Regras vazias devem ser removidas
- As folhas de estilo vazias devem ser removidas
- Experimental @-rules não devem ser usados
- Identificadores experimentais não devem ser usados
- Propriedades experimentais não devem ser usadas
- Pseudo-elementos experimentais e pseudo-classes não devem ser usados
- Combinadores seletores experimentais não devem ser usados
- Os arquivos devem conter uma nova linha vazia no final
- Os arquivos não devem ter muitas linhas
- Os nomes da família de fontes devem ser citados
- Os arquivos de fonte que estão em linha não devem ser usados
- As propriedades da família de fontes devem terminar com uma família de fontes genéricas
- A família não deve conter nomes de família de fontes duplicados
- Propriedades proibidas não devem ser usadas
- Nomes genéricos de família de fontes não devem ser citados
- Definições de gradiente devem ser definidas para todos os fornecedores
- Os seletores de identificação devem seguir uma convenção de nomenclatura
- IDs nos seletores devem ser removidos
- Os zeros principais devem ser removidos
- Linhas não devem demorar muito
- As linhas não devem terminar com os espaços em branco à direita
- Os prefixos de fornecedores ausentes devem ser adicionados às propriedades experimentais
- O nome do elemento superequalificado deve ser removido
- Cores nomeadas não devem ser usadas
- Número de precisão não deve ser muito alto
- Propriedades obsoletas não devem ser usadas
- Pseudo-elementos obsoletos e pseudo-classes não devem ser usados
- Combinadores seletores obsoletos não devem ser usados
- Seletores super especificados devem ser simplificados
- Propriedades que não funcionam com a propriedade "Display" devem ser removidas
- Os valores da propriedade devem ser válidos
- URL de protocolo-relativo não deve ser usado
- Expressão regular como seletores não deve ser usada
- Expressão regular em @-Rule
- Expressão regular no comentário
- Expressão regular na função
- Expressão regular na propriedade
- Expressão regular na unidade
- As propriedades da regra devem ser ordenadas em ordem alfabética
- Propriedades abreviadas devem ser usadas sempre que possível
- Propriedades abreviadas não devem ser usadas
- Citações únicas devem ser usadas em vez de citações duplas para strings
- O código -fonte deve cumprir os padrões de formatação
- Propriedades padrão devem ser especificadas juntamente com propriedades preparadas para fornecedores
- Star Hack não deve ser usado
- As folhas de estilo não devem conter muitas regras
- As folhas de estilo não devem conter muitos seletores
- Os caracteres de tabulação não devem ser usados
- O número de fontes da web deve ser reduzido
- Deve haver uma única declaração por linha
- Zeros à direita para valores numéricos devem ser removidos
- Os tipos de seletores devem ser removidos
- Underscore hack não deve ser usado
- As unidades para valores de comprimento zero devem ser removidas
- O seletor universal não deve ser usado como parte chave
- Desconhecido @-rules deve ser removido
- Propriedades desconhecidas devem ser removidas
- Pseudo-elementos desconhecidos e pseudo-classes devem ser removidos
- Seletores de tipo desconhecido devem ser removidos
- Url 'papel.gif' nunca deve ser usado
- URL deve ser citado
Específico para CSS
- A regra "@import" não deve ser usada
- As regras @Import devem preceder todas as outras regras de regra e estilo
- As variáveis CSS devem seguir uma convenção de nomenclatura
- Funções experimentais não devem ser usadas
- Funções obsoletas não devem ser usadas
- As folhas de estilo não devem "@import" muitas outras folhas
- As funções CSS desconhecidas devem ser removidas
Específico para CSS incorporado em html/xhtml
- CSS não deve ser incorporado em arquivos HTML
Específico para SCSS
- As diretivas @Debug não devem ser usadas no código de produção
- @extend Diretivas não devem ser usadas
- @if ... @else se ... construções devem terminar com a diretiva @else
- Sempre use 'através' em vez de 'para' nas diretivas @for
- As condições não devem ser muito complexas
- Diretivas de fluxo de controle @if, @else se, @else, @for, @while e @each não devem ser aninhadas muito profundamente
- Funções personalizadas devem seguir uma convenção de nomenclatura
- Declarações e diretrizes devem ser classificadas adequadamente
- Strings multilinas descontraídas não devem ser usadas
- Diretiva de fluxo de controle vazio deve ser removido
- Mixins vazios devem ser removidos
- Mixins devem seguir uma convenção de nomenclatura
- Propriedades aninhadas devem definir pelo menos duas propriedades
- Seletores de espaço reservado devem seguir uma convenção de nomenclatura
- @If / @else relacionado se as diretrizes não tiverem a mesma condição
- Os conjuntos de regras não devem ser aninhados muito profundamente
- As variáveis SCSS devem seguir uma convenção de nomenclatura
- Comentários de linha única (//) devem ser preferidos em comentários de várias linhas (/ * ... */)
- Dois ramos na mesma estrutura condicional não devem ter exatamente a mesma implementação
- Parênteses inúteis seguindo @include e @mixin sem parâmetro devem ser removidos
Específico para menos
- A função de fuga "E" depreciada deve ser substituída pela sintaxe ~ "valor"
- Menos variáveis devem seguir uma convenção de nomenclatura
- Os conjuntos de regras não devem ser aninhados muito profundamente
- A mesma variável não deve ser declarada várias vezes dentro do mesmo escopo
- Comentários de linha única (//) devem ser preferidos em comentários de várias linhas (/ * ... */)
- CSS desconhecido / menos funções devem ser removidas
- Variáveis devem ser declaradas no início do bloco
