Accentsconagua
Share
Betydelsen av kodläsbarhet underskattas ofta, särskilt när man programmerar i en miljö som betonar användargränssnitt och användarupplevelse. Medan det är sant att det är oerhört viktigt att göra en bra app, är det lika viktigt att kunna ändra det i framtiden. Med oläslig kod kan det vara mycket svårare att lösa buggar, med otaliga timmar att försöka hitta rätt kodkod och förstå hur det fungerar.
Vilken dåre som helst kan skriva kod som en dator kan förstå. Bra programmerare skriver kod som människor kan förstå. - Martin Fowler
Med det i åtanke, låt oss komma igång och lära dig några sätt att göra din kod mer läsbar både för dig själv och för andra som kanske behöver ändra på det i framtiden.
Det kan tyckas som en uppenbar metod att göra kod mer läsbar, men det är ofta förbisedd. Om du skriver Swift-kod är det troligt att du använder Xcode som en kompilator, och det visar sig att Xcode är fullt med funktioner som gör att din kod blir mer läsbar.
Den vanligaste typen av kommentar är en enstaka kommentar. Massor av oss använder de två snedstreckningarna framför en linje så att den kommer att ignoreras av kompilatorn, men glöm inte hur användbart det är att dokumentera din kod!
Som en uppdatering, så här gör du en traditionell enradig kommentar:
// beräkna medelklassen låt genomsnittet = (gradeA + gradeB + gradeC) / 3.0
Enligt konventet ligger kommentaren över den linje som den förklarar mer detaljerat. Försök använda dina kommentarer för att lägga till förklaring eller inblick i din kod, utöver att bara beskriva vad linjen gör. Till exempel är följande kommentar för koden ovan inte till hjälp, eftersom den inte lägger till någon ytterligare förklaring utöver vad som är omedelbart uppenbart.
// summa betyg och dela med 3
Du kan ha använt Kommando-Klicka för att få mer information om en viss variabel, klass eller metod, men visste du att du kan lägga till information som denna till din egen kod? Du kan! För att göra detta, använd en speciell synkroniserad synkroniserad synkronisering enligt följande: tre snedstreck följt av ett mellanslag och ett streck. Lägg sedan till attributnamnet (till exempel "parameter") och slutligen skriver du ordet och sedan dess definition.
Här är ett exempel på en snabb hjälpkommentarsyntax:
/// - parameter foobar: definition av foo func foobar ()
När du Kommando-klicka de Foo bar funktionen var som helst som den används, ser du dess definition som visas under parametrar.
En mindre använd typ av kommentar är en blockkommentar. Dessa kommentarer brukar användas för att lägga upp licensinformation och upphovsrättsinformation längst upp i filen, men de kan också användas om du behöver skriva flera rader som förklarar din kod (även om det är en bra tumregel att om du behöver så många ord att förklara din kod, det är nog inte läsbar nog).
För att göra en blockkommentation, börja med en snedstreck, en asterisk och sedan din kod. När du är redo att avsluta kommentaren kan du helt enkelt placera en asterisk och sedan ett annat framåt snedstreck.
Här är ett exempel på det:
/ * Copyright (c) 2018, Vardhan Agrawal Alla rättigheter förbehållna. * /
Återgå till snabbhjälpdokumentationen. Blockera kommentarer är det rätta sättet att skapa fullständig dokumentation av din kod inom Xcode. För dessa, använd helt enkelt två asterisker för att starta och avsluta som du skulle för en vanlig blockkommentation med en enda asterisk. Du kan även använda markdown-syntaxen för att formatera din kommentar och göra den mer läsbar.
Så här skulle du dokumentera en kod:
/ ** Den här funktionen returnerar en lista över slumpmässighet. ** Parametrar: ** - foo: lite slumpmässig. - bar: en massa mer slumpmässighet. * /
Börja med att lägga till bra kommentarer till din kod och du kommer att vara ett steg närmare skrivning av läsbar kod.
Du kanske har hört det här mycket, men kod måste kunna läsas som engelska. Faktum är att datorn inte bryr sig en bit om hur det ser ut mot människor, men en av tecknen på en bra programmerare är hur bra de kan formulera sin kod för att vara så läsbar som möjligt.
I Swift är det bäst att namnge saker baserat på den roll som objektet spelar i koden. Till exempel istället för att bara använda namnet äpple för en variabel av typen Äpple, om äpplet tjänar som mat för ett djur, det kan namnges mat istället.
Det kan ibland vara frestande att ge många ansvarsområden till ett objekt som ska vara specialiserat, och det kan göra din app mindre modulär och mer förvirrande för alla som läser koden. Att namnge dina objekt baserat på vad de gör kan hjälpa dig att påminna dig om att bara ge roller till de föremål som de är ansvariga för.
Namnen på ... egenskaper, variabler och konstanter ska läsa som substantiv. - Apple
Denna allmänna tumregel är meningsfullt på grund av den roll som dessa typer spelar i en app är typiskt representerade av substantiv. Här är några exempel:
var poängCounter för en SpriteKit-spelstatusvariabel.låt sharedInstance för en singleton.Användningar av boolesiska metoder och egenskaper bör läsas som påståenden om mottagaren. - Apple
Genom att säga att boolesna "borde vara påståenden om mottagaren", menar vi helt enkelt att de borde vara ja eller nej förklaringar. Låt oss titta på några exempel:
var är Empty för en array.låt touchesEdge för en sprite.Protokoll som beskriver vad som är något borde läsa som substantiv. - Apple
Om du använder protokoll för att skapa en "mall" -typ, ska du använda samma namngivning som du skulle använda för variabler och konstanter. Det här är också bra eftersom du namnger typ av metoder, klasser etc. Här är några exempel:
protokoll Frukter för olika typer av fruktklasser.protokollsamlingar för arrays, listor och mer.Protokoll som beskriver en förmåga bör namnges med suffixerna: kan, ible eller ing. - Apple
Om dina protokoll definierar vad en typ kan göra ska den namnges med suffixerna ovan. Detta bör läsas som om protokollet "kan" göra något. Här är en annan lista med exempel:
protokoll Returnerbart för typer som kan returneras.protokoll ProgressReporting för typer som rapporterar framsteg.Förutom de här namngivningskonventionerna rekommenderar Apple att du undviker vad de kallar "användarvillkor", eller med andra ord, termer som kanske inte är lättförståeliga. De säger inte att undvika dem helt, men använd dem inte när ett grundläggande ord kommer att räcka i stället.
I applikationer med produktionskvalitet använder utvecklare designmönster för att strukturera sin kod på ett sätt som kan ändras och är också mer läsbart. Låt oss diskutera några designmönster som du kan använda i din nästa iOS-app.
Som cliché som det här kan låta är det verkligen grunden för hur du programmerar din app. Låt oss säga att du bygger ett hem, ditt drömhus. Det här huset är fem våningar högt, så om du inte bygger en stark grund och följer ritningarna kommer det förmodligen bara att toppla över. Grunden för en iOS-app är det designmönster eller mönster du väljer. Låt oss titta på två av de vanligaste mönstren.
Modell-View-Controller eller MVC-designmönstret är en industristandard. Det skiljer varje del av din kod i tre delar: modellen, vyn och kontrollenheten.
Det finns många variationer av detta, till exempel MVVM och MVP. Det är värt att läsa på dem,men principen liknar MVC. För mer om MVC och MVVM, ta en titt på dessa artiklar av Bart Jacobs här på Envato Tuts+.
Oavsett vilken du väljer, är de alla kallade designmönster, och de gör vår kod mer modulär. Låt oss titta på ett annat designmönster som kan komplettera det appmönster du väljer att använda.
En singleton är en enda förekomst av en klass som alltid är närvarande i minnet. Så varför bryr vi oss om det här? Tja, låt oss säga att du bygger en app som ansluter till en databas. Du behöver en plats för att sätta alla dina datatjänstanslutningar. Detta skulle vara en perfekt plats att använda singletoner.
Titta på koden nedan - det kommer att visa dig hur man bygger en singleton:
// Deklarationsklass DataService static var shared = DataService () func createUser () // Gör något // Call-site DataService.shared.createUser ()
Det är så enkelt!
Om du använder designmönster blir din kod mycket mer läsbar, såväl som organiserad och modulär, så att du kan isolera problem med din app mycket lättare och göra stora förändringar med minimal kodomvandling.
För att lära dig mer designmönster för Swift, kolla in vår heltäckande kurs.
I kursen lär du dig 21 olika designmönster. Du kan bara hitta en som kommer att förändra hur du kodar!
Som du kan se är det inte så svårt att göra din kod mer läsbar och organiserad. När du försöker göra det, kommer du att dra nytta av lättanpassad kod, liksom att göra din kod lättare för andra att förstå. Arbetsgivare letar efter dessa saker, så vana att använda dessa tips regelbundet!
Jag hoppas att du haft denna handledning, och medan du är här, kolla in några av våra andra handledning på Swift och iOS app utveckling.
