Blog (Română)

Mai multe și mai multe echipe au adoptat linters și alte static instrumente în procesul lor de dezvoltare. Unii le-au integrat în IDE-ul preferințelor lor, alții le-au automatizat rulându-le ca un pas suplimentar în CI-ul lor. De asemenea, unii rulează în ambele sensuri.

ce este un linter, atunci?

Conform Wikipedia, linter

este un instrument care analizează codul sursă pentru a semnala erori de programare, bug-uri, erori stilistice, și suspecte constructe.,

primul linter a fost scris de Stephen C. Johnson în 1978 în timp ce lucra în sistemul de operare Unix la Bell Labs. După aceea, multe alte lintere au apărut pentru diferite scopuri și limbi, nu numai C.

primele lintere utilizate pentru a verifica codul sursă și pentru a găsi optimizări potențiale pentru compilatoare. Dar, de-a lungul anilor, multe alte verificări și analize ar fi incluse în procesul de căptușire.utilizarea linters a ajutat, de asemenea, mulți dezvoltatori să scrie un cod mai bun pentru limbajele de programare necompilate., Deoarece nu există compilarea erorilor de timp, găsirea de greșeli, erori de sintaxă, utilizări ale variabilelor nedeclarate, apeluri către funcții nedefinite sau depreciate, de exemplu, ajutând dezvoltatorii să o remedieze mai repede și să reducă erorile înainte de execuție.

Linterii au evoluat

Linterii au evoluat. Au început cu acele verificări simple, dar în zilele noastre devin din ce în ce mai sofisticate. Ei efectuează analize statice, impun steaguri de configurare, verifică respectarea unui anumit ghid de stil sau a unei reguli de securitate și multe altele.,să explorăm câteva dintre aceste verificări și cum pot fi utile pentru dvs.

analiza statică

analiza statică înseamnă că software-ul automat rulează prin sursa de cod fără a o executa. Verifică static eventualele erori, scurgeri de memorie și orice altă verificare care poate fi utilă.

dacă sunteți un dezvoltator Python, este posibil să știți deja Radon. Poate număra liniile sursă ale codului (SLOC), liniile de comentarii, o linie goală și alte valori brute, dar, de asemenea, poate calcula un „indice de întreținere”, care poate fi foarte important în unele proiecte.

acesta este doar un exemplu., Există o mulțime de alte linii care efectuează verificări de analiză statică.

Free E-book: Click aici pentru a descărca gratuit E-book decodare cod de revizuire și trage cereri. Obțineți toate punctele cheie și cele mai bune practici pentru a implementa o cultură de revizuire a codurilor.

Cod standardizarea

https://xkcd.com/1285/

Standardizarea codul dvs. este o modalitate foarte bună de a muta conversația spre o viață mai productivă nivel., Având un ghid și care rulează linters împotriva codebase evită modificările estetice în cererea pull, cum ar fi înlocuirea tuturor filelor pentru spații, indentarea o atribuire variabilă, sau chiar pauze de linie după un anumit număr de caractere.maximizarea modificărilor semnificative duce discuția la subiecte care contează, cum ar fi decizii arhitecturale, probleme de securitate sau potențiale erori.apropo, probleme de securitate și potențiale bug-uri, de asemenea, pot fi evitate de linters!

probleme de securitate

Dacă sunteți în Rails, probabil ați auzit despre Brakeman., Este un instrument de securitate analiză statică. Este benefic pentru a găsi potențiale probleme de securitate. De exemplu, se execută verificări în căutarea SQL Injection atunci când se utilizează ActiveRecord lui #find_or_create_by și prieteni. De asemenea, adaugă verificări pentru XSS, Opțiuni de configurare și multe altele.Ruby nu este singura limbă cu acest tip de motor. SourceLevel suportă o mulțime de motoare pentru diferite limbi. Brakeman inclus.

potențiale erori

JavaScript are câteva trucuri. Una dintre cele mai cunoscute este diferența dintre == și ===., Este o practică bună și evită mult timp de depanare, pentru a utiliza întotdeauna ===. Dacă activați, de exemplu, ESLint pentru a verifica acest lucru, vă poate spune ce parte a codului dvs. utilizează == și chiar să o înlocuiți pentru dvs.

îmbunătățiri ale performanței

fiecare dezvoltator experimentat cunoaște nu numai importanța efectuării de software, ci și multe trucuri care îl îmbunătățesc. Problema este: Ce zici de noii veniți? Cum poți transmite aceste cunoștințe mai departe? Chiar și programatorii seniori pot pierde o tehnică sau două. Deci, de ce să nu lăsați un software de automatizare să o facă pentru dvs.?,știați că în CSS, selectorul universal ( * ) poate încetini un timp de încărcare a paginii? Sau că selectorii de atribute necalificați au aceleași caracteristici de performanță ca selectorul universal? Evitarea lor este o practică bună.multe linii includ o verificare a performanței. Ele pot adăuga diferite tipuri de îmbunătățiri de performanță pentru dezvoltatorii cu experiență și nou-veniți. CSSLint este doar un exemplu.

și multe alte aspecte

la infinit și dincolo!, Există o mulțime de lintere pentru diferite limbaje de programare, fișiere de configurare și chiar pentru integrări software. Orice verificare care contează și poate fi automatizată se poate transforma într-un linter.

dacă lucrați într-un anumit scenariu, va trebui să scrie linter dvs., chiar dacă nu este prea probabil în industria noastră. Verificările pentru caracteristicile de accesibilitate HTML, erorile potențiale de internalizare, erorile gramaticale și multe altele sunt deja acolo, open-source, așteptând să descărcați, să configurați și să începeți să utilizați.

beneficiile linting

conform Ferit T.,, linting îmbunătățește lizibilitatea, elimină erorile stupide înainte de execuție și revizuirea codului. Dar, după cum sa menționat, linting pot face locuri de muncă mai complexe, cum ar fi detectarea cod miroase sau efectuarea de analiza statica de cod.dar ,în practică, care sunt avantajele căptușelii?

îmbunătățește nivelul discuției de revizuire a codului

dacă solicitarea Dvs. de tragere nu are greșeli de ortografie sau variabile neutilizate și este conformă cu ghidul de stil, conversația tinde să se concentreze pe punctul de vedere al arhitecturii. Asta e., Solicitarea Pull este un loc minunat pentru a indica problemele de performanță, vulnerabilitățile titlurilor de valoare sau pentru a sugera abstracții mai bune. Nu aveți nevoie pentru a obține în care ghilimele simple sau duble sau tab vs spații discuție. Este un câștig de productivitate sigur.

face ca Codul să pară scris de o singură persoană

pe termen mediu și lung, având o bază de cod fiabilă care pare scrisă de aceeași persoană este excelentă. Mentenabilitatea și evoluția sunt mai ușoare, deoarece toată lumea tinde să înțeleagă ceea ce este scris mai rapid și mai precis., Acesta previne bug-uri, face loc de muncă mai vesel pentru dezvoltatori, și accelerează timpul de piață de noi caracteristici.

oferă vizibilitate a sănătății codebase

este codul sănătos? Nu vei ști până nu-l măsori. Un mod interesant de a face acest lucru este de a adăuga un pas în conducta CI/CD pentru a măsura evoluția stării de sănătate a codului. Mai bine decât atât, puteți lua măsuri cât mai curând posibil atunci când vedeți că sănătatea sa se degradează., Astfel de acțiuni pot implica pe crearea de carduri de debit tehnice în bord sau chiar ridica problema în timpul agile retrospectivă sau arhitectura Comitetului de întâlnire.

răspândește conștientizarea și proprietatea asupra calității codului

dezvoltatorii cu experiență pot analiza o diferență și pot ridica probleme relevante cu privire la modificarea propusă. Probabil că știu unde să se uite: sunt variabile nume descriptive? Câte linii ia o metodă? Există vreo superclasă?

dar ce zici de noii veniți? Cunoștințele dintr-o echipă sunt adesea eterogene. Aceasta înseamnă că nu fiecare dezvoltator știe ce să se uite peste cod., A avea un linter pentru a spune unde sunt automat mirosurile de cod este o modalitate excelentă de a răspândi aceste cunoștințe și de a face echipa responsabilă pentru schimbări.calitatea nu este o responsabilitate pentru o singură persoană. Este esențial să măsurați și să controlați calitatea codului în timp. În caz contrar, codul devine dezordonat, ceea ce încetinește dezvoltarea și timpul de lansare pe piață.,

Controale tehnice datorii

Ca mulți modern linters caute tehnice posibile datorii, cum ar fi codul de mirosuri, ghid de stil nepotriviri, sau prost concepute cod (adâncime lanțuri de if declarații, sau prea complexe metode, de exemplu), linters se corelează cu datoria tehnică.

Face tehnice datoriile explicit în codul procesul de revizuire a ajuta dezvoltatorii de software sau ingineri de la fața locului, de a discuta și de a-l repara înainte de a merge în master ramură. Este o practică foarte convenabilă care controlează inserțiile tehnice ale datoriilor.,

Automatizați revizuirea Codului: SourceLevel acceptă +30 de linii pentru a vă ajuta să îmbunătățiți calitatea codului. Faceți clic aici pentru a vedea un demo sau pentru a începe o încercare gratuită.

Exemple de linters

există un număr mare de linters acolo. În funcție de limbajul de programare, există chiar mai mult de un Linter pentru fiecare lucrare. De exemplu, pentru limbajul de programare Go, există ktlint și detekt. Ambele efectuează o muncă similară. La fel se întâmplă și cu eslint, un linter conceput pentru JavaScript. Funcționează foarte similar cu tslint sau jshint.,

Linters axat pe Securitate

  • Frânar pentru Ruby
  • Bandit pentru Python
  • Nodul de Securitate pentru JavaScript

Linters axat pe ghidul de stil și convențiile de codificare

  • CSSLint., SCSS Scame și Sass Scame pentru Foaie de Stil în Cascadă
  • Gofmt pentru limba
  • Swiftlint pentru Switft
  • rustfmt pentru Rugina
  • Credo pentru Elixir

Linters de Analiză Statică

  • pep8 pentru Python
  • Phan sau PHP Mizerie Detector pentru PHP
  • kibit pentru Clojure, ClojureScript, cljx, și alte Clojure variante.
  • PMD pentru Java

concluzie

Linters vă ajută să obțineți mai productiv și să economisiți timp și bani. Acestea conduc echipa la decizii mai bune (cele orientate pe date) și împărtășesc proprietatea asupra calității.,

la SourceLevel, susținem o mulțime de linters. Ei rulează împotriva fiecărei cereri de tragere deschise și comentează linia corectă și fișier problemele găsite. Aceasta crește productivitatea și eficiența dezvoltatorilor.

noi o numim automatizarea revizuirii codului. Fiecare depozit poate avea fișierul său de configurare și apoi poate revizui cererile pull în conformitate cu regulile alese de ghid de stil.

Share

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *