Accentsconagua
Share
Betydningen av kodelesbarhet er ofte undervurdert, spesielt når du programmerer i et miljø som legger vekt på brukergrensesnitt og brukeropplevelse. Selv om det er sant at det er ekstremt viktig å lage en flott app, er det like viktig å kunne endre det i fremtiden. Med ulestelig kode kan det være mye vanskeligere å løse feil, med utallige timer med å prøve å finne de riktige kodelinjene og forstå hvordan det fungerer.
Enhver idiot kan skrive kode som en datamaskin kan forstå. Gode programmerere skriver kode som mennesker kan forstå. - Martin Fowler
Med det i tankene, la oss komme i gang og lære noen måter å gjøre koden din mer lesbar både for deg selv og for andre som kanskje må gjøre endringer i det i fremtiden.
Dette kan virke som en åpenbar metode for å gjøre koden mer lesbar, men det blir ofte overset. Hvis du skriver Swift-kode, er det sannsynlig at du bruker Xcode som en kompilator, og det viser seg at Xcode er fullpakket med funksjoner som gjør at koden din blir mer lesbar.
Den mest brukte typen kommentar er en enkeltlinje kommentar. Mange av oss bruker de to fremoverstrekkene foran en linje slik at den blir ignorert av kompilatoren, men ikke glem hvor nyttig det er å dokumentere koden din!
Som en oppdatering, her er hvordan du gjør en tradisjonell en linje kommentar:
// beregne gjennomsnittsklassen la gjennomsnitt = (klasseA + klasseB + klasseC) / 3.0
Av konvensjonen er kommentaren over linjen som den forklarer mer detaljert. Prøv å bruke kommentarene dine for å legge til forklaring eller innsikt i koden din, utover bare å beskrive hva linjen gjør. For eksempel er følgende kommentar for koden ovenfor ikke nyttig, fordi den ikke legger til noen ytterligere forklaring utover det som umiddelbart er tydelig.
// summen karakterene og divisjonen med 3
Du har kanskje brukt Kommando-Klikk for å få mer informasjon om en bestemt variabel, klasse eller metode, men visste du at du kan legge til informasjon som denne til din egen kode? Du kan! For å gjøre dette, bruk en spesiell kommentarsyntaks på en linje som følger: Tre skråstreker, etterfulgt av et mellomrom og en dash. Deretter legger du til attributtnavnet (for eksempel "parameter") og til slutt skriver du ut ordet, og deretter definisjonen.
Her er et eksempel på en rask hjelpekommentar syntaks:
/// - parameter foobar: definisjon av foo func foobar ()
Når du Kommando-klikk de foobar fungere hvor som helst det er brukt, vil du se sin definisjon vist under parametere.
En mindre utbredt type kommentar er en blokkkommentar. Disse kommentarene brukes vanligvis til å legge inn lisensinformasjon og opphavsrettsinformasjon øverst i filen, men de kan også brukes hvis du trenger å skrive flere linjer som forklarer koden din (selv om det er en god tommelfingerregel at hvis du trenger så mange ord til forklar koden din, det er sannsynligvis ikke lesbar nok).
For å lage en blokkkommentasjon, start med en foroverstrekk, en stjerne, og deretter koden din. Når du er klar til å avslutte kommentaren, kan du bare plassere en stjerne og deretter et annet fremoverstreke.
Her er et eksempel på det:
/ * Opphavsrett (c) 2018, Vardhan Agrawal Alle rettigheter reservert. * /
Å komme tilbake til hurtighjelpedokumentasjonen, blokkere kommentarer er den riktige måten å opprette full dokumentasjon av koden din i Xcode. For disse, bruk bare to stjerner for å starte og avslutte som du ville for en vanlig blokkkommentar med en enkelt stjerne. Du kan til og med bruke markdown-syntaksen til å formatere kommentaren din og gjøre den mer lesbar.
Slik dokumenterer du noen kode:
/ ** Denne funksjonen returnerer en liste over tilfeldighet. ** Parametre: ** - foo: litt tilfeldig. - bar: en gjeng mer tilfeldig. * /
Begynn å legge til gode kommentarer til koden din, og du vil være ett skritt nærmere å skrive lesbar kode.
Du har kanskje hørt dette mye, men koden må kunne lese som engelsk. Faktisk bryr datamaskinen seg ikke en bit om hvordan det ser ut til mennesker, men et tegn på en god programmerer er hvor bra de kan artikulere deres kode for å være så lesbar som mulig.
I Swift er det best å nevne ting basert på rollen som objektet spiller i koden. For eksempel, i stedet for bare å bruke navnet eple for en variabel av typen eple, hvis epleet tjener som mat til et dyr, kan det bli navngitt mat i stedet.
Det kan noen ganger være fristende å gi mange ansvar til et objekt som skal spesialiseres, og dette kan gjøre appen din mindre modulær og mer forvirrende for alle som leser koden. Å navngi dine objekter basert på hva de gjør kan hjelpe deg å minne deg om å bare gi roller til de objektene de er ansvarlige for.
Navnene på ... egenskaper, variabler og konstanter bør leses som substantiver. - Eple
Denne generelle tommelfingerregelen er fornuftig på grunn av hvilken rolle disse typene spiller i en app, vanligvis representeres av substantiver. Her er noen eksempler:
var scoreCounter for en SpriteKit-spilltilstandsvariabel.la sharedInstance for en singleton.Bruk av boolske metoder og egenskaper bør leses som påstander om mottakeren. - Eple
Ved å si at boolesker "burde være påstand om mottakeren", betyr det bare at de skal være ja eller nei erklæringer. La oss se på noen få eksempler:
var erEmpty for en matrise.la touchesEdge for en spillsprite.Protokoller som beskriver hva noe er, bør leses som substantiver. - Eple
Hvis du bruker protokoller for å lage en "mal" -type, bør du bruke samme navn som du vil bruke for variabler og konstanter. Dette gir også mening fordi du navngir typen metoder, klasser, etc. Her er noen eksempler:
protokoll Frukter for ulike typer fruktklasser.protokollsamlinger for arrays, lister og mer.Protokoller som beskriver en evne bør bli navngitt ved hjelp av suffikser: kan, ible eller ing. - Eple
Hvis protokollene dine definerer hva en type kan gjøre, bør den bli navngitt med suffiksene ovenfor. Dette bør leses som om protokollen er "i stand til" å gjøre noe. Her er en annen liste med eksempler:
protokoll Returnerbar for typer som kan returneres.protokoll ProgressReporting for typer som rapporterer fremgang.I tillegg til disse navngivningskonvensjonene anbefaler Apple også at du unngår det de kaller "kunstverk", eller med andre ord, vilkår som kanskje ikke er lett forståelige. De sier ikke å unngå dem helt, men ikke bruk dem når et grunnord vil være nok i stedet.
I apper med produksjonskvalitet bruker utviklere designmønstre for å strukturere koden på en måte som kan endres og er også mer lesbar. La oss diskutere noen designmønstre som du kan bruke i din neste iOS-app.
Som kliché da dette kan høres, er dette virkelig grunnlaget for hvordan du programmerer appen din. La oss si at du bygger et hjem, ditt drømmehus. Dette huset er fem etasjer høyt, så hvis du ikke bygger et sterkt fundament og følger tegningene, vil det sannsynligvis bare topple over. Grunnlaget for en iOS-app er designmønsteret eller mønstrene du velger. La oss se på to av de mest brukte mønstrene.
Modell-View-Controller eller MVC design mønster er en industristandard. Det skiller hver del av koden i tre deler: modellen, visningen og kontrolleren.
Det er mange variasjoner av dette, for eksempel MVVM og MVP. Det er verdt å lese på dem,men prinsippet ligner på MVC. For mer om MVC og MVVM, ta en titt på disse artiklene av Bart Jacobs her på Envato Tuts+.
Uansett hvilken du velger, er de alle kalt designmønstre, og de gjør koden mer modulær. La oss se på et annet designmønster som kan utfylle app-mønsteret du velger å bruke.
En singleton er en enkelt forekomst av en klasse som alltid er til stede i minnet. Så hvorfor bryr oss oss om dette? Vel, la oss si at du bygger en app som kobles til en database. Du trenger et sted for å sette alle dine datatjenesteforbindelser. Dette ville være et perfekt sted å bruke singletoner.
Se på koden nedenfor - det vil vise deg hvordan du bygger en singleton:
// Deklarasjonsklasse DataService static var shared = DataService () func createUser () // Gjør noe // Call-site DataService.shared.createUser ()
Det er så enkelt!
Hvis du bruker designmønstre, vil koden din bli mye mer lesbar, så vel som organisert og modulær, slik at du kan isolere problemer med appen din mye lettere og gjøre store endringer med minimal kodeomkobling..
For å lære mer design mønstre for Swift, sjekk ut våre full lengde kurs.
I dette kurset lærer du 21 forskjellige designmønstre. Du kan bare finne en som vil forandre måten du kode på!
Som du ser, er det ikke så vanskelig å gjøre koden mer lesbar og organisert. Når du gjør en innsats for å gjøre det, vil du ha nytte av enkle å endre kode, samt gjøre koden enklere for andre å forstå. Arbeidsgivere ser etter disse tingene, så vant å bruke disse tipsene med jevne mellomrom!
Jeg håper du likte denne opplæringen, og mens du er her, sjekk ut noen av våre andre opplæringsprogrammer på Swift og iOS app utvikling.
