Bruke SwiftLint og Danger for hurtige fremgangsmåter

Dette innlegget ble opprinnelig dukket opp i Swift Post, tilgjengelig her.

Apples Swift blir mer og mer populær blant utviklermiljøet. De fleste av oss begynte allerede å tilpasse prosjektene våre til dette folket. Mens vi adopter, er vi kanskje ikke så forsiktige som vi burde være, da Swift er et veldig fleksibelt språk og det er veldig enkelt å misbruke det. Spesielt som kommer fra en Objekt-C-kultur, blir det viktig å anvende beste praksis.

Etter å ha lest Swifty Tips fra Göksel, innså jeg at et par av tipsene hans kan sjekkes automatisk med SwiftLint. Vi er også late mennesker, og vi har en tendens til å glemme å sjekke koden vår før vi går sammen om å mestre. Akkurat her kommer Danger på scenen med blanke klær og påpeker at vi gjør noe farlig.

Høres interessant ut.. Men hva er disse verktøyene, faktisk?

SwiftLint

SwiftLint er et open source-verktøy for å håndheve Swift-stil og konvensjoner. Den er utviklet av Realm. Du kan angi kodingsstilreglene dine og tvinge dem under utvikling. SwiftLint har et kommandolinjeverktøy, Xcode-plugin, AppCode og Atom-integrasjon. Så det passer alltid til utviklingsmiljøet ditt. Det vil vise deg advarsler og / eller feil hvis du bryter loftsreglene.

Du kan se på installasjonsveiledning og opplæring herfra. Etter installasjonen har du noen regler som standard. For eksempel advarer det når du bruker privat IBOutlet eller tvinger bort pakking i tilleggsutstyr.

La oss ta en titt på Göksels tips. Han sier: "Bruk aldri implisitt utpakkede tilleggsutstyr." SwiftLint gir dette som standard nøyaktig hvordan han beskriver. SwiftLint vil advare deg når du implisitt pakker bort et valgfritt, med mindre det er IBOutlet. Den andre er “Unngå _ misbruk”. SwiftLint er smart nok til å påpeke når du ikke bruker de avgrensede alternativene.

hvis la _ = Foo.optionalValue {} // Trigers en advarsel
if case. Noen (la _) = self {} // Utløser en advarsel
if foo () {let _ = bar ()} // Ikke utløser en advarsel
if foo () {_ = bar ()} // Ikke utløser en advarsel

I tillegg til å anvende beste fremgangsmåter individuelt, ønsker vi å lage kodebasen konsistent. Gjør det lettere å bruke tilpassede regler. Disse reglene bør imidlertid passe best praksis. Konfigurering av fôring håndteres fra .swiftlint.yml-filen. Denne filen ligger i prosjektets hovedsti. Vi kan aktivere, deaktivere eller skrive tilpassede regler i denne YML-filen. La oss se på noen eksempler.

Første ting først, å skrive en stor funksjon er generelt et dårlig tegn. Hvis funksjonen din blir større, betyr det at du bør dele ansvaret. Legg til følgende kodestykke til filen .swiftlint.yml. Dette advarer utviklerne om å ha funksjoner under 200 linjer. Hvis programmerer når 300, genererer SwiftLint en feil. Husk at du kan ignorere advarsler, men ikke feil.

function_body_length:
 - 200 # advarsel
 - 300 # feil

Nesten hvert prosjekt har avhengigheter eller kodestykker som ikke er mulig å endre. Disse kodestykkene skal ikke lenses i det hele tatt. Hvis et prosjekt for eksempel bruker CocoaPods som avhengighetsansvarlig, vil det ha Pods-mappen som beholder alle avhengighetsfiler. Vi må ekskludere denne mappen fra fôringsprosessen. Som du ser nedenfor, er det så enkelt.

ekskludert:
  - Pods

Enten selskapets retningslinjer eller utvikler som jobber i prosjektet har en kodingsstil. SwiftLint hjelper nykommere å tilpasse seg disse stilene under onboarding-prosessen.

Som du så fra eksempler, er det som gir det ekstra løftet for SwiftLint fleksibilitet. Noen ganger må du bryte reglene i spesielle linjer eller filer. Disse situasjonene ble behandlet i SwiftLint med spesielle kommentarer. Du kan bruke følgende til å justere regler i disse tilfellene.

Legg til denne kommentaren for å deaktivere regelen i filen:

// swiftlint: deaktiver regelnavn

Legg til denne kommentaren for å deaktivere regelen på følgende linje:

// swiftlint: deaktiver: neste regelnavn

Legg til denne kommentaren for å deaktivere regelen i forrige linje:

// swiftlint: deaktivere: forrige regelnavn

Du kan få listen over alle regler ved å kjøre kommandoer for hurtigregler i terminalen.

Til slutt fullførte vi reglene våre, og nå kan vi kode i fred. Men til og med i noen tilfeller, må du være mer forsiktig enn å bare bruke dine lofteregler. Det er her Danger kommer på plass.

P.S .: Du kan finne min forhåndsdefinerte .swiftlint.yml-fil her .

Fare ️

Hvert prosjekt / kodestykke har sin egen spesifikke flyt. Når prosjektet vokser, blir det vanskeligere å vedlikeholde og legge til nye funksjoner. Feil utsatt øker. Å ha retningslinjer for koding og anvende beste fremgangsmåter er generelt ikke nok. Vi er mennesker, vi gjør feil. Fare kan fange grunnleggende feil og la oss tenke de vanskeligere problemene. For eksempel kan den fange vanlige skrivefeil eller genererte filendringer som du ikke bør endre selv. Det kan også tvinge deg til å skrive tester hvis du skriver mer enn 20 kodelinjer. Reglene er i dine hender som de samme som SwiftLint.

Danger er en Ruby perle som kjører i CI under trekkforespørsel / fusjon forespørselsprosess. Det etterlater meldinger, kommentarer eller til og med mislykkes i CI-byggingen når reglene dine brytes. Danger kan kjøre på flere CI-verktøy og kan chatte på GitHub, Bitbucket og GitLab.

Fare kan legge igjen meldinger, advarsler, feil på PR / MR. Kilde: fare.systems

Du kan følge installasjonsveiledningen her for å installere Danger i CI-prosessen. Danger bruker reglene fra et Ruby-manus skrevet i Dangerfile. La oss se hva vi kan gjøre der inne.

For enkeltansvar og enklere kodegjennomgang, bør utviklere ikke åpne store pull-forespørsler. Hvis en pull-forespørsel har mer enn 600 linjer med kode, bør det være en advarsel om å dele opp pull-forespørselen. Fare kan gi dette en enkelt konfigurasjonslinje:

advarer "Stor PR, vurder å dele opp i mindre" hvis git.lines_of_code> 600

Hva annet? Hvis du jobber med Test-After-utviklingsprosessen, kan du lett glemme å skrive tester. På den annen side bør det være en automatisk måte å kommentere “Du har glemt å legge til tester”. Generelt, hvis du endrer mer enn 20 kodelinjer, bør du skrive tester. Antall linjer avhenger av avgjørelsen din, men du har ideen. La oss se hvordan vi kan oppnå dette med fare:

## La oss sjekke om det er noen endringer i prosjektmappen
has_app_changes =! git.modified_files.grep (/ ProjectName /). tom?
## Da bør vi sjekke om testene er oppdatert
has_test_changes =! git.modified_files.grep (/ ProjectNameTests /). tom?
## Til slutt, la oss kombinere dem og sette ekstra betingelse
## for endret antall kodelinjer
hvis has_app_changes &&! has_test_changes && git.lines_of_code> 20
  mislykkes ("Testene ble ikke oppdatert", klebrig: usann)
slutt

Fare passer for alle slags prosjekter. Det gir et bredt spekter av konfigurasjoner til flere språk med plugins. I Swift-tilfellet utviklet Ash Furrow en plugin for SwiftLint. Takket være denne plugin-modulen, kan vi ha SwiftLint-advarsler som kommentarer i trekningen. Du kan se installasjonsveiledning her. Etter installasjonen, må du legge til en av følgende linjer for å avslutte Dangerfile.

swiftlint.lint_files
swiftlint.lint_files inline_mode: true

Dangerfile sikrer at utviklingsretningslinjene dine brukes på koden. Det gjør deg mer selvsikker. På lang sikt lærer advarsler deg om å være mer forsiktig. Det er en referansehåndbok her for å gi deg mer detaljert oversikt over fares muligheter.

Merk: Du trenger ikke å konfigurere CI. Det er mulig å kjøre fare på din lokale maskin med fare lokal kommando.

Takket være Erens svar, kan du alltid bruke følgende kommando hvis den lokale kommandoen for fare ikke går over den siste åpne PR-en:

fare pr https: // YOUR_PR_URL --dangerfile = YOUR_DANGERFILE_PATH

P.S .: Du finner min forhåndsdefinerte Dangerfile her .

Bonus: SwiftLint med Git Hook

Hvis du jobber med forskjellige tekstredigerere eller IDEer som SwiftLint ikke støtter, kan du bare bruke kommandolinjeværktøy for å feste koden. Dette er et ekstra skritt, og det er lett å glemme. Bra, vi kan automatisere dette. Hook-funksjonen i Git er et annet sted å automatisere ting. I utgangspunktet er Git-kroker skript der Git utfører før eller etter hendelser som begå, skyve og motta. Vi kan kjøre SwiftLint i et av disse skriptene. Personlig bruker jeg SwiftLint i forhåndsforpliktelsen mens jeg skriver Swift i sublim tekst.

P.S .: Du kan finne min fulle forhåndsforpliktende krok her in. Hvis du vil bruke det samme, er det bare å plassere filen ovenfor under mappen .git / hooks i prosjektet. (Du vil se eksempler på krokskript der inne. Plasser det blant dem.) Du kan også bruke som en annen krok. Du kan se på listen over tilgjengelige kroker og mer informasjon her.

Slutten

La Danger og SwiftLint håndtere de trivielle tingene for deg. Fra nå av kan du hoppe over grunnleggende problemer og fokusere på mer kompliserte ting under kodegjennomgang. SwiftLint og Danger sikrer at alt er på plass som du vil. Vil du prøve?

Takk for at du leser️! Hjelp til med å spre ordet .

Har du spørsmål, forslag, kommentarer eller ideer til kommende blogginnlegg? Kontakt meg på Twitter eller skriv en kommentar! Du kan også følge meg på GitHub.

Mine andre innlegg:

  • Bruke Firebase Cloud Messaging for eksterne varsler i iOS
  • Første erfaringer på serversiden innen Swift - HTTP-metoder og databasedrift
  • Gjør Swift Backend API-testbar - Enhetstester i Swift-serversiden-applikasjonen