há algum tempo atrás eu assisti um desenvolvedor júnior, que tem um problema aparente em seu código, para descobrir o que estava errado nele. Ele instalou um cotão e baixou (Deus sabe por que) um dicionário personalizado para ele. Preparei um pequeno ambiente de teste e mostrei-lhe a diferença entre diferentes testes, em diferentes pontos e algumas limitações de cada um (neste pequeno ambiente).
recentemente eu estava falando sobre testes com um colega e eu me lembrei desta anedota e disse a mim mesmo para escrever um post sobre isso, como poderia ser interessante para muitos.,o que é linting?
Linting é a verificação automática do seu código-fonte para erros programáticos e estilísticos. Isto é feito usando uma ferramenta de cotão (t. c. p.linter). Uma ferramenta de lint é um analisador de código estático básico.
O termo linting vem originalmente de um utilitário Unix para C. Existem muitos linters de código disponíveis para várias linguagens de programação hoje.
programação Lint é um tipo de verificação automatizada. Pode acontecer no início do desenvolvimento, antes de revisões de código e testes. Isso é porque verificações de código automatizadas tornam a revisão de código e os processos de teste mais eficientes., E eles libertam os seus programadores para se concentrarem nas coisas certas.
Muitas ferramentas de teste automatizadas tirar proveito de um built-in a linter para lançar os erros, definir algumas pontuação sobre qualidade de código e bloquear a compilação ou a implantar o estágio, se este índice é menor do que o desejado (automaticamente ou pausar o processo de atirar uma notificação para verificar manualmente se este “erros” deve ser corrigido ou não).
para que se destina?
Linting destina-se a reduzir erros e melhorar a qualidade geral do Código devs, acelerar o desenvolvimento e reduzir os custos, encontrando erros mais cedo.,
quando usar software de Fibra Óptica?
Se isso é novo para você, você pode ser algum tipo de hyped com lints neste ponto, mas eles não são uma ferramenta programagicamente. Um cotão é simplesmente um scrapper / file reader script com um arquivo (geralmente um JSON ou xml) com regras predefinidas (ou personalizadas) sobre como o código deve se parecer. De fato, os IDEs têm uma cor incorporada que lhe dará um erro (ou seja, se você chamar um método inexistente, ou se você tentar adicionar um valor de cadeia em uma variável inteira) ou um aviso (ou seja,, se você declarar uma variável dentro de uma condicional e então você retornar essa variável no final de seu método). Mas eu não estou falando sobre o fio de código embutido, como estes linters são “suaves” e permissivos, caso contrário muitas pessoas não vão usar esses IDEs, veremos porquê mais tarde.
pode utilizar um fio de algodão específico se se enquadrar nestas afirmações:
Quando utiliza linguagens de programação interpretadas.
algumas línguas são mais adequadas para a confecção de códigos do que outras. PHP, Python e JavaScript são linguagens interpretadas, o que significa que eles não têm uma fase de compilação*., Assim, o uso de software lint é eficaz para garantir um estilo de codificação consistente e resolver erros básicos de codificação nestes casos.
mas, quando se trata de linguagens compiladas, como C E C++, o uso de software lint pode não ser suficiente. C E C++ são complexos e podem exigir uma análise de código mais avançada.você pode estar gritando eu compilo JavaScript! mas não é verdade. Hoje em dia, no front end estamos usando ferramentas como bundlers, adicionando algumas ferramentas javascript que passam nossos js por algumas fases, tais como minify, ugglify, ofuscate. Algumas dessas ferramentas também eliminam o código não utilizado em sua saída., Mas nenhuma destas coisas significa que você está compilando javascript, como a saída será a .ficheiro js de qualquer forma; sem bytecode, sem montador.
é verdade que você pode converter javascript em web assembly, mas não é um caminho direto de um para outro; você deve converter seu js em algo “compilável” tal código C e, em seguida, compilá-lo em web assembly.
Quando você usa regras padrão
esta é uma afirmação um pouco complicada., Em uma linguagem de programação você não será capaz de usar algo que não está incorporado em sua linguagem de Programação (Isso não é verdade em tudo, como você pode adicionar bibliotecas ou lançar comandos de Sistema de linguagens de programação, mas de qualquer forma Lint não tem nada a ver com isso…)
What Standard Rules stand for?usando um framework irá caber aqui, você deve usar métodos de framework built-in para alcançar a saída desejada.às vezes regras padrão significa código de moda., Este metodologias e soluções que a comunidade repita como um mantra até que encontrar outra moda caminho para alcançar a meta de uma determinada tarefa, ou até alguém com repercussão pública diz que a comunidade “ei, eu estava analisando este soluções alternativas e eu acho que há uma melhor maneira de alcançar isto por razões” e, em seguida, a comunidade se move.
Quando as suas necessidades são básicas
Ferramentas de Lint são grandes para a análise básica. Mas se você precisa de uma análise mais sofisticada, você deve procurar em outro lugar (Ferramentas de teste automatizadas e desenvolvimento orientado por teste).onde devo ver um fio dental?
1., Em testes automatizados (nós os chamamos de automatizados porque eles executam automaticamente, mas alguém precisa codificar o teste para cada caso de uso em um app), como o Cypress, você pode adicionar um cotão para marcar a qualidade do Código.
isto pode ser executado no tempo de desenvolvimento (quando o dev carrega no botão de teste) ou provavelmente no estágio de implantação. Por exemplo, quando você empurra algo para o master branch pode ser um gatilho para aumentar os testes, incluindo o cotão, e bloquear a implantação (e culpá-lo) se você fez algo errado, então você vai precisar reparar ou encontrar o bug (isso não significa que a culpa é sua., Eu poderia empurrar uma API que faz seu cliente crash receber valores inesperados, e isso será culpa minha, não sua).
estes testes não são destinados a culpá-lo, mas para ajudar no processo de desenvolvimento, geralmente é melhor encontrar um bug antes de se integrar na fase de pré-produção devido a uma falha de teste do que encontrá-lo de surpresa na produção.2. Em grandes projectos, geralmente em grandes empresas., Se você estiver em uma empresa muito grande o gerente de projeto deve, como todo o código parecido com o mesmo (formatação), então eles provavelmente têm um fiapo para ele em algum lugar que ponto você se você adicionou 4 espaços em branco para avançar algo que eles querem com 2 e que irá culpá-lo se você não se declare um método com camelo caso, por exemplo.,
eu acho tons de junior devs tentando lutar contra isso porque eles gostam de alguma formatação particular, mas sem estas ferramentas, este grande aplicativos de software vai se parecer com um monstro frankenstein em um futuro, aumentando a dificuldade em ler todas as partes ou seguindo alguns caminhos de método e substituições de classe. Pense nisso como ler um livro onde cada parágrafo tem um tamanho de letra diferente, família de letra e assim.onde não usá-lo?
este ponto é tão fácil: não o use em contexto dinâmico e em linguagens não programáveis. 1. O primeiro é fácil de entender., Se você estiver em um contexto dinâmico o fio de algodão (um verificador estático) nunca saberá o resultado final e irá culpá-lo por coisas que estão OK, vou adicionar algum exemplo no próximo ponto.2. Isso deve soar ridículo, redundante ou você pode me dizer ” onde você usa um cotão se não está em uma linguagem de programação?”
Mulder, existem linters HTML e CSS por aí.Sim.. hum… Mas como?,
Bem, eles não são “linters” na verdade, eles são apenas o código-damas, o mesmo você pode fazer com o validador do w3c, mas, em vez de copiar seu código para um avaliador, eles geralmente são executados em tempo de desenvolvimento de te culpar por coisas diferentes com base na opinião de alguém, o que é chato, imprecisas e realmente não se encaixa hoje em dia o uso de duas tecnologias (ou três, se você adicionar ESCS), e o mais importante, eles geralmente não têm um motivo para cada instrução, ou os motivos que contradizem a partir de um ponto a outro, ou a razão está desatualizado, ou se as razões não são aplicáveis a todos os projetos., É por isso que você vai encontrar tons de “Esqueça sobre CSSLint, é opinativo e não se encaixa seu projeto” comentários e muitos outros semelhantes em toda a internet.
Você pode encontrar alguns pedaços de código que são chamados de Linters por alguma razão, mas pelo menos eles dizem a você “Eu sou um formador de código opinativo” como este .,
HTML fiapos poderia ser útil, às vezes, como ele irá forçar você a adicionar um atributo ” alt ” para imagens e outros de acessibilidade e boas práticas (a Maioria das IDEs mostra um aviso para ele também, sem a adição de uma fibra, o que é melhor) mas isso não o impede de usar uma <span> <p> ou outro mau html de uso.
também o chateará se estiver a escrever componentes de modelos com declarações tolas como ” não tem declaração doctype, não tem html, cabeça, título ou etiqueta corporal., E você poderia coisa “é claro que, como este arquivo será carregado dentro de um documento que já tem este tags” HTML, mas fiapos não pode saber; Lints são estáticos, damas e você estiver trabalhando em um ambiente dinâmico, então, mover e excluir html fiapos em tudo.
CSSLint é um pouco diferente, não há nada que você possa lint aqui de qualquer maneira, você pode escrever CSS válido ou inválido, mas isso é tudo.,
existem boas práticas em CSS que são para fins de eficiência e velocidade( também irá beneficiar a UX), outras que irão para fins de manutenção, escalabilidade e legibilidade (geralmente com base na experiência de desenvolvimento), outras são para acessibilidade (com base em estudos UI/UX e renderizações de navegador, testes de contraste de tela e assim). Mas não vale a pena combiná-lo todo em um linter e dizer aos devs para combinar com todas essas práticas, em primeiro lugar porque há contradições que precisam de um humano para tomar a decisão de usar um ou outro.,
um caso de Utilização onde escolher pode ser tratado pelo facto de que a adição de todo o código CSS de acessibilidade irá, observavelmente, aumentar o tamanho, o tempo de carregamento e as métricas interactivas da primeira vez, de modo que normalmente irá escolher apenas as regras de acessibilidade que melhor se adequam aos seus clientes, mantendo o bom desempenho.
para definir um exemplo tolo sobre uma regra opinativa sobre o CSSLint digamos que eu quero um gradiente linear como fundo no meu bloco principal da página inicial. O CSSLint lançará um aviso sobre o desempenho de gradiente linear.,
Neste ponto CSSLint quer que você apague o gradiente linear, mas quais são as alternativas?usando uma imagem serão tons de vezes menos eficientes para alcançar o projeto alvo (e também irá reduzir a qualidade visual do gradiente, e vai tornar mais difícil redimensionar para caber todos os tamanhos posíveis do bloco). então o que podemos fazer? Simplesmente ignore o CSSLint, porque é opinativo e isso não é suportado por nenhuma razão. há uma diferença na adição de um gradiente linear vs a adição de 42342 gradientes lineares na mesma vista., A propósito, Se você precisar deles, ele ainda será mais eficiente do que usar imagens.
Você também pode encontrar afirmações contraditórias sobre ele, tais como:
“não use IDs para o estilo”. A razão é que será uma regra não reutilizável.
E
“Don’t use adjacing classes”. Eu não poderia descobrir corretamente a razão sem ler a explicação das regras do CSS lint e a razão é “embora tecnicamente permitido no CSS, estes não são tratados corretamente pelo Internet Explorer 6 e mais cedo”.tenho uma coisa para te dizer, CSSLint., Ninguém se importa com o IE 6 e antes, estamos em 2020, 99% do Software Web suporta I. E. 11 tanto, que foi lançado em 2013 a propósito e tem menos de 3% de uso.por outro lado, onde, por amor de Deus, se expressa que todas as regras CSS têm de ser reutilizáveis na mesma vista?se você tem um item único no seu aplicativo web, ou seja, você provavelmente tem apenas um navbar, apenas um popup de chat Se houver, apenas um logotipo navbar e apenas um rodapé para nomear alguns, por que você precisa adicionar que é estilo global? Não é uma prática tão má que é contrária a todas as outras línguas do mundo?,
Como uma adição, digamos que você tem 5 Visualizações sobre o seu projeto. Se você tiver um <nav> será provavelmente mostrado em todos eles, de modo que o mesmo estilo que você colocou abaixo #primary-navigation está trabalhando em 5 visões diferentes. Não é uma maneira de reutilizar?
para aumentar a tolice em torno de que ambas as regras em conjunto, veja como ele permite que você em uma situação difícil.,
Se você não pode usar um id para estilizar <nav class="dark-theme">, e você não pode adicionar adjacentes classes<nav class="primary-navigation dark-theme">, como você irá gerenciar o escopo do seu estilo, tornando-a mais sustentável, legível e como você pode gerenciá-lo para adicionar java-script de ouvintes de eventos quando necessário, de uma forma eficiente?
Você simplesmente não pode.
O que poderíamos fazer semanticamente correto e fácil de manter?, Vamos dar um exemplo:
Aqui está outra afirmação que me faz rir por um tempo:
evite os selectores de atributos não qualificados “os selectivos de atributos não qualificados, como , corresponder todos os elementos primeiro e, em seguida, verificar os seus atributos. Isto significa que os selectores de atributos não qualificados têm as mesmas características de desempenho que o selector universal (*)”
minha querida, isto não é diferente do que acontece quando se usa classe, id ou selector de marcas.
as fases de renderização de css do navegador São:
- construindo o DOM., O DOM é uma estrutura de dados em árvore contendo todos os nós HTML na página. Cada nó contém os dados sobre esse elemento HTML (como atributos, ids e classes) se o nó tem quaisquer elementos HTML como crianças, ele também irá apontar para esses nós-filhos. construir a CSSOM. Quando o navegador encontra uma folha de estilo CSS (embutida ou externa), ele precisa processar o texto em algo que ele pode usar para layouts de estilo e tintas. A estrutura de dados em que o navegador transforma CSS é criativamente chamada CSSOM.gerando uma árvore de renderização., Em resumo, a árvore de renderização contém toda a informação necessária para que o navegador crie pixels na página. O navegador basicamente pega o DOM e o CSSOM e os esmaga juntos, removendo qualquer coisa que não tenha um efeito na saída renderizada.disposição e pintura.
na fase de Layout, o navegador descobre o tamanho e a posição dos elementos (ainda nada renderizado) e então, no passo de pintura, começa a gerar pixels que vamos visualizar.,
Como você pode ver, você poderia obter um desempenho um pouco de viés quando o aninhamento de forma indiscriminada seu seletores, como body>#main-content>.first-block .products-card p como você vai gerar desnecessários criança nós no CSSOM que precisará coincidir com o DOM e isso vai levar um pouco mais de tempo do que usar simplesmente um.products-card p, mas como é necessário manter este código e, provavelmente, escala, devemos âmbito de aplicação as regras então vamos dizer #main-content .products-card p.
é uma boa prática, mas eu nunca vi um aplicativo web em que seletores mais específicos estão causando gargalo de velocidade de carga., Isto geralmente é causado pela iteração repetidamente mantendo tons de código não usado que o navegador irá adicionar em CSSOM e terá de comparar com DOM para descobrir se é OK adicioná-lo na árvore de renderização ou não.
Por esta e outras razões é por que você pode encontrar artigos explicando cada ponto errado no CSSLint como este que explicam as coisas de uma forma mais extensa do que eu fiz aqui.
resumo
Linters são bons para algumas coisas e maus para outras.,
eles também podem ser editados para atender a algumas necessidades de projeto ou algumas preferências de empresa ou pessoa para evitar essas regras que são opinadas e adicionar outras regras valiosas que se encaixam no projeto em que você está.
Existem muitas razões para se utilizar o “linters” em linguagens interpretadas (compilado, o IDE e o compilador vai cuidar do presente, mas você também pode adicionar um Fiapo para verificar a formatação de código ou apenas para obter avisos antes de compilar, para evitar a espera até o compilador encontra um erro ou extremidades para saber se está tudo OK).,
Há poucas razões para adicionar linters em HTML (apenas propósitos de Acessibilidade podem ser úteis, eu acho) e há menos razões para adicionar linters em CSS (que pode ser reduzido a um código um verificador de formatação).usou um cotão? Em caso afirmativo, diga-nos em que língua e contexto e qual foi a sua experiência.
eu pessoalmente gostei após alguns ajustes ao usar TypeScript.como sempre, espero que goste deste post e melhores cumprimentos.