Introduksjon til FindBugs

1. Oversikt

FindBugs er et open source-verktøy som brukes til å utføre statisk analyse på Java-kode.

I denne artikkelen skal vi se på å sette opp FindBugs på et Java-prosjekt og integrere det i IDE og Maven-bygningen.

2. FindBugs Maven-plugin

2.1. Maven-konfigurasjon

For å begynne å generere statiske analyserapporter, må vi først legge til FindBugs-plugin i vår pom.xml:

   org.codehaus.mojo findbugs-maven-plugin 3.0.4 

Du kan sjekke ut den nyeste versjonen av programtillegget på Maven Central.

2.2. Rapportgenerering

Nå som vi har Maven-pluginet riktig konfigurert, la oss generere prosjektdokumentasjonen ved hjelp av mvn nettsted kommando.

Rapporten genereres i mappen mål / nettsted i prosjektkatalogen under navnet findbugs.html.

Du kan også kjøre mvn findbugs: gui kommando for å starte GUI-grensesnittet for å bla gjennom de genererte rapportene for det aktuelle prosjektet.

FindBugs-pluginet kan også konfigureres til å mislykkes under noen omstendigheter - ved å legge til kjøringsmålet Sjekk til vår konfigurasjon:

 org.codehaus.mojo findbugs-maven-plugin 3.0.4 Maks sjekk 

De innsats - når det maksimeres, utfører en mer fullstendig og presis analyse, og avslører flere feil i koden, men det bruker mer ressurser og tar mer tid å fullføre.

Du kan nå kjøre kommandoen mvn bekrefte, for å sjekke om byggingen vil lykkes eller ikke - avhengig av feilene som ble oppdaget mens analysen kjøres.

Du kan også forbedre rapportgenereringsprosessen og ta mer kontroll over analysen ved å legge til noen grunnleggende konfigurasjoner i plugin-erklæringen:

 org.baeldung.web.controller. * FindNullDeref FindReturnRef 

De bare analyser alternativet erklærer en kommaadskilt verdi av klasser / pakker som er kvalifisert for analyse.

De besøkende/utelate besøkende alternativene er også kommaseparerte verdier, de brukes til å spesifisere hvilke detektorer som skal / ikke skal kjøres under analysen - Merk det besøkende og utelate besøkende kan ikke brukes samtidig.

En detektor er spesifisert etter klassens navn, uten noen pakkekvalifisering. Finn detaljene for alle tilgjengelige detektorer ved å følge denne lenken.

3. FindBugs Eclipse Plugin

3.1. Installasjon

IDE-installasjonen av FindBugs Plugin er ganske grei - du trenger bare å bruke programvareoppdateringsfunksjonen i Eclipse, med følgende oppdateringsside: //findbugs.cs.umd.edu/eclipse.

For å sikre at FindBugs er riktig installert i Eclipse-miljøet, må du se etter alternativet merket FindBugs under Windows -> Innstillinger -> Java.

3.2. Rapporter surfer

For å starte en statisk analyse på et prosjekt ved hjelp av FindBugs Eclipse-plugin, må du høyreklikke på prosjektet i pakkeutforskeren, og deretter klikke på alternativet merket finne feil.

Etter lansering viser Eclipse resultatene under Bug Explorer-vinduet som vist på skjermbildet nedenfor:

Fra versjon 2 begynte FindBugs å rangere feil med en skala fra 1 til 20 for å måle alvorlighetsgraden av feil:

  • Skremmeligst: rangert mellom 1 og 4.
  • Skummelt: rangert mellom 5 og 9.
  • Plagsom: rangert mellom 10 og 14.
  • Av bekymring: rangert mellom 15 og 20.

Mens feilrangeringen beskriver alvorlighetsgraden, gjenspeiler tillitsfaktoren sannsynligheten for at disse feilene blir flagget som virkelige. Tilliten ble opprinnelig kalt prioritet, men det ble omdøpt i den nye versjonen.

Selvfølgelig kan noen feil være åpen for tolkning, og de kan til og med eksistere uten å skade den ønskede oppførselen til en programvare. Derfor må vi i en reell situasjon konfigurere statiske analyseverktøy riktig ved å velge et begrenset sett med feil å aktivere i et bestemt prosjekt.

3.3. Formørkelseskonfigurasjon

FindBugs-plugin gjør det enkelt å tilpasse strategien for feilanalyse ved å tilby forskjellige måter å filtrere advarsler på og begrense strengheten til resultatene. Du kan sjekke konfigurasjonsgrensesnittet ved å gå til Window -> Preferences -> Java -> FindBugs:

Du kan fritt fjerne merket for uønskede kategorier, heve minimum rangering for å rapportere, angi minimum tillit for rapportering, og tilpasse markører for feilranger - Advarsel, Info eller Feil.

FindBugs deler feil i mange kategorier:

  • Korrekthet - samler generelle feil, f.eks. uendelige løkker, upassende bruk av er lik(), etc
  • Dårlig praksis, f.eks. unntakshåndtering, åpnede strømmer, strengesammenligning osv
  • Opptreden, f.eks. inaktive gjenstander
  • Flertrådet korrekthet - samler synkroniseringsinkonsekvenser og forskjellige problemer i et miljø med flere tråder
  • Internasjonalisering - samler problemer knyttet til koding og applikasjonens internasjonalisering
  • Skadelig kodesårbarhet - samler sårbarheter i kode, f.eks. kodebiter som kan utnyttes av potensielle angripere
  • Sikkerhet - samler sikkerhetshull relatert til spesifikke protokoller eller SQL-injeksjoner
  • Dodgy - samler kodelukt, f.eks. ubrukelige sammenligninger, nullkontroller, ubrukte variabler osv

Under Detektor konfigurasjon på fanen, kan du sjekke reglene du skal respektere i prosjektet ditt:

Hastighetsattributtet gjenspeiler hvor kostbar analysen vil være. Jo raskest detektoren, den minste ressursene som forbrukes for å utføre den.

Du finner den uttømmende listen over feil som gjenkjennes av FindBugs på offisiell dokumentasjonsside.

Under Filtrer filer panelet, kan du opprette egendefinerte filfiltre for å inkludere / ekskludere deler av kodebasen. Denne funksjonen er nyttig - for eksempel - når du vil forhindre "ikke-administrert" eller "søppel" -kode, mangler som dukker opp i rapportene, eller kan ekskludere for eksempel alle klasser fra testpakken.

4. FindBugs IntelliJ IDEA-plugin

4.1. Installasjon

Hvis du er en IntelliJ IDEA-fan, og du vil begynne å inspisere Java-kode ved hjelp av FindBugs, kan du ganske enkelt hente plugin-installasjonspakken fra det offisielle JetBrains-nettstedet og trekke den ut til mappen% INSTALLATION_DIRECTORY% / plugins. Start IDE på nytt, så er du klar.

Alternativt kan du navigere til Innstillinger -> Plugins og søke i alle arkiver etter FindBugs-plugin.

Når denne artikkelen skrives, er versjonen 1.0.1 av IntelliJ IDEA-plugin-programmet akkurat ute,

For å sikre at FindBugs-plugin er riktig installert, sjekk etter alternativet merket “Analyser prosjektkode” under Analyser -> FindBugs.

4.2. Rapporter surfer

For å starte statisk analyse i IDEA, klikk på “Analyser prosjektkode” under Analyser -> FindBugs, og se etter FindBugs-IDEA-panelet for å inspisere resultatene:

Du kan bruke den andre kolonnen med kommandoer på venstre side av skjermbildet for å gruppere feil ved å bruke forskjellige faktorer:

  1. Gruppere etter en feilkategori.
  2. Grupper etter en klasse.
  3. Gruppere etter en pakke.
  4. Grupper etter en feilrangering.

Det er også mulig å eksportere rapportene i XML / HTML-format, ved å klikke på "eksport" -knappen i den fjerde kolonnen med kommandoer.

4.3. Konfigurasjon

FindBugs-plugin-preferansesidene i IDEA er ganske selvforklarende:

Dette innstillingsvinduet er ganske likt det vi har sett i Eclipse, slik at du kan utføre alle slags konfigurasjoner på en analog måte, fra analyseinnsatsnivå, feilrangering, selvtillit, filtrering av klasser, etc.

Innstillinger-panelet er tilgjengelig i IDEA, ved å klikke på “Plugin-preferanser” -ikonet under FindBugs-IDEA-panelet.

5. Rapportanalyse for Spring-Rest Project

I denne delen skal vi belyse en statisk analyse gjort på vårhvile-prosjektet som er tilgjengelig på Github som et eksempel:

De fleste av manglene er mindre - av bekymring, men la oss se hva vi kan gjøre for å fikse noen av dem.

Metoden ignorerer eksepsjonell returverdi:

File fileServer = ny fil (filnavn); fileServer.createNewFile ();

Som du sikkert kan gjette, klager FindBugs over det faktum at vi kaster returverdien til createNewFile () metode. En mulig løsning vil være å lagre den returnerte verdien i en nylig deklarert variabel, og deretter logge noe meningsfylt ved hjelp av DEBUG-loggnivået - f.eks. “Den navngitte filen eksisterer ikke og ble opprettet”Hvis den returnerte verdien er sann.

Metoden kan mislykkes i å stenge strømmen unntatt: denne spesielle mangelen illustrerer en typisk brukssak for unntakshåndtering som antyder alltid lukke bekker i en endelig blokkere:

prøv {DateFormat dateFormat = ny SimpleDateFormat ("åååå_MM_dd_HH.mm.ss"); Strengfilnavn = dateFormat.format (ny dato ()); File fileServer = ny fil (filnavn); fileServer.createNewFile (); byte [] byte = file.getBytes (); BufferedOutputStream stream = new BufferedOutputStream (new FileOutputStream (fileServer)); stream.write (byte); stream.close (); returner "Du har lastet opp" + brukernavn; } fange (Unntak e) {return "Du klarte ikke å laste opp" + e.getMessage (); }

Når et unntak kastes før stream.close () instruksjon, er strømmen aldri stengt, det er derfor det alltid er å foretrekke å bruke endelig{} blokker for å lukke bekker åpnet i løpet av en prøve/å fange rutine.

An Unntak blir fanget når Unntak blir ikke kastet: Som du kanskje allerede vet, fanger Unntak er en dårlig kodingspraksis, FindBugs mener at du må fange et mest spesifikt unntak, slik at du kan håndtere det ordentlig. Så i utgangspunktet manipulere strømmer i en Java-klasse, fange IO Unntak ville være mer passende enn å fange et mer generisk unntak.

Feltet ble ikke initialisert i konstruktøren, men ble referert uten nullkontroll: det er alltid en god ide å initialisere felt inne i konstruktører, ellers bør vi leve med muligheten for at koden vil heve en NPE. Derfor anbefales det å utføre nullkontroller når vi ikke er sikre på om variabelen er riktig initialisert eller ikke.

6. Konklusjon

I denne artikkelen har vi dekket de grunnleggende nøkkelpunktene for å bruke og tilpasse FindBugs i et Java-prosjekt.

Som du kan se, er FindBugs et kraftig, men likevel enkelt statisk analyseverktøy, det hjelper å oppdage potensielle kvalitetshull i systemet ditt - hvis det er innstilt og brukt riktig.

Til slutt er det verdt å nevne at FindBugs også kan kjøres som en del av et eget kontinuerlig automatisk kodevurderingsverktøy som Sputnik, som kan være veldig nyttig for å gi rapportene mye mer synlighet.

Eksempelkoden vi brukte for statisk analyse er tilgjengelig på Github.