SwiftLint en Danger gebruiken voor Swift Best Practices

Dit bericht is oorspronkelijk verschenen in Swift Post, hier beschikbaar.

Apple's Swift wordt steeds populairder bij de ontwikkelaarsgemeenschap. De meesten van ons begonnen onze projecten al aan te passen aan deze folk. Bij het adopteren zijn we misschien niet zo voorzichtig als we zouden moeten zijn, want Swift is een zeer flexibele taal en het is echt gemakkelijk om het te misbruiken. Vooral afkomstig uit een Objective-C-cultuur, wordt het toepassen van best practices erg belangrijk.

Na het lezen van Swifty Tips van Göksel, realiseerde ik me dat een paar van zijn tips automatisch kunnen worden gecontroleerd met SwiftLint. We zijn ook luie mensen en hebben de neiging om te vergeten onze code te controleren voordat we samenvoegen tot master. Hier komt Danger met glanzende kleding het podium op en wijst erop dat we iets gevaarlijks doen.

Klinkt interessant ... Maar wat zijn deze tools eigenlijk?

SwiftLint

SwiftLint is een open source-tool om Swift-stijl en conventies af te dwingen. Het is ontwikkeld door Realm. U kunt uw codeerstijlregels instellen en deze tijdens de ontwikkeling forceren. SwiftLint heeft een opdrachtregelprogramma, Xcode-plug-in, AppCode en Atom-integratie. Het past dus altijd in uw ontwikkelomgeving. Er worden waarschuwingen en / of fouten weergegeven als u de regels voor linting overtreedt.

U kunt vanaf hier de installatiehandleiding en zelfstudie bekijken. Na de installatie zijn er standaard enkele regels. Het waarschuwt bijvoorbeeld wanneer u privé-IBOutlet gebruikt of het uitpakken van opties afdwingt.

Laten we de tips van Göksel eens bekijken. Hij zegt: "Gebruik nooit impliciet uitpakken van opties". SwiftLint biedt dit standaard precies zoals hij beschrijft. SwiftLint waarschuwt u wanneer u impliciet een optie uitpakt, behalve als het IBOutlet is. De andere is "Vermijden _ misbruik". SwiftLint is slim genoeg om aan te geven wanneer u uw gebonden opties niet gebruikt.

if let _ = Foo.optionalValue {} // Trigers een waarschuwing
if case .some (let _) = self {} // Hiermee wordt een waarschuwing geactiveerd
if foo () {let _ = bar ()} // activeert geen waarschuwing
if foo () {_ = bar ()} // Geeft geen waarschuwing

Naast het toepassen van best practices afzonderlijk, willen we de codebase consistent maken. Maak het eenvoudiger om aangepaste regels toe te passen. Deze regels moeten echter wel passen bij best practices. Het configureren van linting wordt afgehandeld vanuit het .swiftlint.yml-bestand. Dit bestand bevindt zich in het hoofdpad van het project. We kunnen aangepaste regels in dit YML-bestand inschakelen, uitschakelen of schrijven. Laten we enkele voorbeelden bekijken.

Allereerst is het schrijven van een grote functie over het algemeen een slecht teken. Als uw functie groter wordt, betekent dit dat u de verantwoordelijkheid moet verdelen. Voeg het volgende codestuk toe aan uw .swiftlint.yml-bestand. Dit waarschuwt ontwikkelaars voor functies met minder dan 200 regels. Als het programmeerapparaat 300 bereikt, genereert SwiftLint een fout. Vergeet niet dat u waarschuwingen kunt negeren, maar geen fouten.

function_body_length:
 - 200 # waarschuwing
 - 300 # fout

Bijna elk project heeft afhankelijkheden of codestukken die niet kunnen worden gewijzigd. Deze codestukken mogen helemaal niet worden gepluisd. Als een project bijvoorbeeld CocoaPods gebruikt als afhankelijkheidsbeheer, heeft het een map met pods die alle afhankelijkheidsbestanden bewaart. We moeten deze map uitsluiten van het linting-proces. Zoals je hieronder kunt zien, is het zo eenvoudig.

uitgesloten:
  - Pods

Bedrijfsrichtlijnen of ontwikkelaars die aan het project werken, hebben een coderingsstijl. SwiftLint helpt nieuwkomers om deze stijlen over te nemen tijdens het onboarding-proces.

Zoals u uit voorbeelden zag, is flexibiliteit de extra boost voor SwiftLint. Soms moet je de regels breken in speciale regels of bestanden. Deze situaties werden behandeld in SwiftLint met speciale opmerkingen. U kunt het volgende gebruiken om regels in deze gevallen aan te passen.

Voeg deze opmerking toe om de regel in het bestand uit te schakelen:

// swiftlint: regelnaam uitschakelen

Voeg deze opmerking toe om de regel op de volgende regel uit te schakelen:

// swiftlint: uitschakelen: volgende regelnaam

Voeg deze opmerking toe om de regel in de vorige regel uit te schakelen:

// swiftlint: uitschakelen: vorige regelnaam

U kunt de lijst met alle regels krijgen door de opdracht swiftlint rules in terminal uit te voeren.

Eindelijk hebben we onze regels afgerond en nu kunnen we in vrede coderen. Maar zelfs in sommige gevallen moet u voorzichtiger zijn dan alleen uw pluisregels toepassen. Dit is waar gevaar op zijn plaats komt.

P.S .: U kunt mijn voorgedefinieerd .swiftlint.yml-bestand hier vinden .

Gevaar ️

Elk project / stuk code heeft zijn eigen specifieke stroom. Wanneer het project groeit, wordt het onderhouden en toevoegen van nieuwe functies moeilijker. Foutgevoelig neemt toe. Het hebben van coderingsrichtlijnen en het toepassen van best practices zijn meestal niet voldoende. We zijn menselijk, we maken fouten. Gevaar kan fundamentele fouten opvangen en laat ons de moeilijkere problemen bedenken. Het kan bijvoorbeeld veelvoorkomende typefouten of gegenereerde bestandswijzigingen bevatten die u niet zelf zou moeten wijzigen. Het kan je ook dwingen om tests te schrijven als je meer dan 20 regels code schrijft. De regels zijn in jouw handen als bij SwiftLint.

Gevaar is een Ruby-edelsteen die in CI wordt uitgevoerd tijdens het pull-aanvraag / merge-aanvraagproces. Het laat berichten, opmerkingen achter of mislukt zelfs uw CI-build wanneer uw regels worden overtreden. Danger kan op verschillende CI-tools worden uitgevoerd en kan chatten op GitHub, Bitbucket en GitLab.

Gevaar kan berichten, waarschuwingen of fouten achterlaten op de PR / MR. Bron: danger.systems

U kunt de installatiehandleiding hier volgen om Gevaar in uw CI-proces te installeren. Danger past de regels toe van een Ruby-script geschreven in Dangerfile. Laten we eens kijken wat we daar kunnen doen.

Voor individuele verantwoordelijkheid en eenvoudiger codebeoordeling mogen ontwikkelaars geen grote pull-aanvragen openen. Als een pull-verzoek meer dan 600 regels code bevat, moet er een waarschuwing zijn om het pull-verzoek te splitsen. Danger kan dit voorzien van een enkele configuratielijn:

waarschuw "Big PR, overweeg om in kleinere te splitsen" als git.lines_of_code> 600

Wat nog meer? Als u werkt met het Test-After-ontwikkelingsproces, kunt u gemakkelijk vergeten om tests te schrijven. Aan de andere kant zou er een geautomatiseerde manier moeten zijn voor "Je bent vergeten om tests toe te voegen" opmerkingen. Over het algemeen moet u tests schrijven als u meer dan 20 coderegels wijzigt. Het aantal lijnen hangt af van uw beslissing, maar u kreeg het idee. Laten we eens kijken hoe we dit kunnen bereiken met Gevaar:

## Laten we controleren of er wijzigingen zijn in de projectmap
has_app_changes =! git.modified_files.grep (/ ProjectName /). leeg?
## Dan moeten we controleren of tests zijn bijgewerkt
has_test_changes =! git.modified_files.grep (/ ProjectNameTests /). leeg?
## Tot slot, laten we ze combineren en extra voorwaarde stellen
## voor gewijzigd aantal regels code
if has_app_changes &&! has_test_changes && git.lines_of_code> 20
  mislukken ("Tests zijn niet bijgewerkt", sticky: false)
einde

Gevaar is geschikt voor elk soort project. Het biedt een breed scala aan configuraties voor verschillende talen door plug-ins. In Swift ontwikkelde Ash Furrow een plug-in voor SwiftLint. Dankzij deze plug-in kunnen we SwiftLint-waarschuwingen hebben als inline opmerkingen in het pull-verzoek. U kunt de installatiehandleiding hier bekijken. Na de installatie moet u een van de volgende regels toevoegen aan het einde van uw gevarenbestand.

swiftlint.lint_files
swiftlint.lint_files inline_mode: true

Dangerfile zorgt ervoor dat uw ontwikkelingsrichtlijnen op uw code worden toegepast. Het maakt je zelfverzekerder. Op de lange termijn leren waarschuwingen je om voorzichtiger te zijn. Hier vindt u een naslaggids voor een gedetailleerder overzicht van de mogelijkheden van Danger.

Opmerking: u hoeft CI niet te configureren. Het is mogelijk om Gevaar op uw lokale machine uit te voeren met lokaal commando voor gevaar.

Dankzij het antwoord van Eren, als het lokale commando gevaar niet wordt uitgevoerd over de laatste open PR, kun je altijd het volgende commando gebruiken:

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

P.S .: U kunt mijn vooraf gedefinieerde Dangerfile hier vinden .

Bonus: SwiftLint met Git Hook

Als u werkt met verschillende teksteditors of IDE's die SwiftLint niet ondersteunt, kunt u alleen opdrachtregelprogramma's gebruiken om uw code te pluiseren. Dit is een extra stap en het is gemakkelijk om te vergeten. Maar goed, we kunnen dit automatiseren. Hook-functie in Git is een andere plek om dingen te automatiseren. Kortom, Git hooks zijn scripts waar Git voor of na evenementen uitvoert zoals commit, pushen en ontvangen. We kunnen SwiftLint in een van deze scripts uitvoeren. Persoonlijk gebruik ik SwiftLint in de pre-commit hook terwijl ik Swift aan het schrijven ben in Sublime Text.

P.S .: Je kunt mijn volledige pre-commit hook hier vinden . Als je hetzelfde wilt gebruiken, plaats je het bovenstaande bestand gewoon onder de map .git / hooks in je project. (U ziet hier voorbeelden van haakscripts. Plaats deze tussen hen.) U kunt ook als een andere haak gebruiken. U kunt de lijst met beschikbare haken en meer informatie hier bekijken.

Het einde

Laat Danger en SwiftLint de triviale dingen voor je regelen. Vanaf nu kun je basisproblemen overslaan en je concentreren op meer gecompliceerde dingen tijdens het herzien van de code. SwiftLint en Danger zorgen ervoor dat alles op zijn plaats is zoals u wilt. Wil je het proberen?

Bedankt voor het lezen️! Help het woord verspreiden.

Heb je vragen, suggesties, opmerkingen of ideeën voor aankomende blogposts? Neem contact met mij op Twitter of schrijf een reactie! Je kunt me ook volgen op GitHub.

Mijn andere berichten:

  • Firebase Cloud Messaging gebruiken voor externe meldingen in iOS
  • Eerste server-side ervaringen in Swift - HTTP-methoden en databasebewerkingen
  • Swift Backend API testbaar maken - Unit-tests in Swift server-side applicatie