Accentsconagua
Share
Het belang van codele leesbaarheid wordt vaak onderschat, vooral bij het programmeren in een omgeving die de gebruikersinterface en gebruikerservaring benadrukt. Hoewel het klopt dat het uiterst belangrijk is om een geweldige app te maken, is het net zo belangrijk om deze in de toekomst te kunnen wijzigen. Met onleesbare code kan het veel moeilijker zijn om bugs op te lossen, met talloze uren proberen om de juiste coderegels te vinden en te begrijpen hoe het werkt.
Elke dwaas kan code schrijven die een computer kan begrijpen. Goede programmeurs schrijven code die mensen kunnen begrijpen. - Martin Fowler
Met dat in gedachten, laten we aan de slag gaan en enkele manieren leren om uw code leesbaarder te maken, zowel voor uzelf als voor anderen, die in de toekomst mogelijk wijzigingen moeten aanbrengen..
Dit lijkt een voor de hand liggende methode om code leesbaarder te maken, maar wordt vaak over het hoofd gezien. Als je Swift-code schrijft, is het waarschijnlijk dat je Xcode als een compiler gebruikt, en handig blijkt dat Xcode vol zit met functies die je code leesbaarder maken.
Het meest gebruikte type opmerking is een commentaar met één regel. Veel van ons gebruiken de twee schuine strepen vooraan voor een regel, zodat deze door de compiler worden genegeerd, maar vergeet niet hoe nuttig het is om uw code te documenteren!
Als een opfriscursus, hier is hoe een traditionele regel met enkele regel te doen:
// bereken het gemiddelde cijfer laat gemiddelde = (cijferA + cijferB + cijferC) / 3.0
Volgens afspraak ligt de opmerking boven de regel die meer in detail wordt uitgelegd. Probeer uw opmerkingen te gebruiken om uitleg of inzicht in uw code toe te voegen, dan alleen maar te beschrijven wat de regel doet. De volgende opmerking voor de bovenstaande code is bijvoorbeeld niet nuttig, omdat deze geen verdere uitleg toevoegt die verder gaat dan wat onmiddellijk zichtbaar is.
// som de cijfers en deel door 3
Je hebt misschien gebruikt Command-Click voor meer informatie over een bepaalde variabele, klasse of methode, maar wist u dat u informatie zoals deze aan uw eigen code kunt toevoegen? Jij kan! Gebruik hiervoor een speciale syntaxis voor de syntaxis van een enkele regel: drie schuine strepen, gevolgd door een spatie en een liggend streepje. Voeg vervolgens de kenmerknaam toe (bijvoorbeeld "parameter") en tenslotte typ je het woord en vervolgens de definitie ervan.
Hier is een voorbeeld van een syntaxis voor snelle hulp:
/// - parameter foobar: definition of foo func foobar ()
Wanneer je Command-Click de foobar overal waar het gebruikt wordt, zie je de definitie hieronder parameters.
Een minder vaak gebruikt type commentaar is een blokcommentaar. Deze opmerkingen worden meestal gebruikt om licentiegegevens en auteursrechtinformatie boven aan het bestand te plaatsen, maar ze kunnen ook worden gebruikt als u meerdere regels moet schrijven die uw code uitleggen (hoewel het een goede vuistregel is dat als u zoveel woorden nodig hebt om leg uw code uit, hij is waarschijnlijk niet leesbaar genoeg).
Als u een blokcommentaar wilt maken, begint u met een schuine streep, een asterisk en vervolgens uw code. Zodra u klaar bent om de opmerking te beëindigen, kunt u eenvoudig een asterisk en vervolgens een andere schuine streep plaatsen.
Hier is een voorbeeld van:
/ * Copyright (c) 2018, Vardhan Agrawal Alle rechten voorbehouden. * /
Terugkeren naar de quick help-documentatie, het blokkeren van opmerkingen is de juiste manier om volledige documentatie van uw code binnen Xcode te maken. Gebruik hiervoor gewoon twee sterretjes om te beginnen en te eindigen zoals bij een gewone blokcommentaar met één sterretje. U kunt zelfs de markdown-syntaxis gebruiken om uw opmerking te formatteren en leesbaarder te maken.
Dit is hoe je een code zou kunnen documenteren:
/ ** Deze functie retourneert een lijst met willekeurigheid. ** Parameters: ** - foo: een beetje willekeur. - bar: een hoop meer willekeur. * /
Begin met het toevoegen van goede opmerkingen aan uw code en u komt een stap dichter bij het schrijven van leesbare code.
Je hebt dit misschien al vaak gehoord, maar de code moet in staat zijn om als Engels te lezen. Eigenlijk maakt de computer het niet uit hoe het eruit ziet voor de mens, maar een van de tekenen van een goede programmeur is hoe goed ze hun code kunnen verwoorden om zo leesbaar mogelijk te zijn.
In Swift kun je het best dingen benoemen op basis van de rol die het object in de code speelt. Bijvoorbeeld, in plaats van alleen de naam te gebruiken appel voor een variabele van het type appel, als de appel als voedsel voor een dier dient, kan het worden genoemd voedsel in plaats daarvan.
Het kan soms verleidelijk zijn om veel verantwoordelijkheden te geven aan een object dat gespecialiseerd zou moeten zijn, en dit kan uw app minder modulair en verwarrend maken voor iedereen die de code leest. Door uw objecten een naam te geven op basis van wat ze doen, kunt u eraan herinneren dat u alleen rollen moet geven aan de objecten waarvoor ze verantwoordelijk zijn.
De namen van ... eigenschappen, variabelen en constanten moeten als zelfstandige naamwoorden worden gelezen. - Appel
Deze algemene vuistregel is logisch vanwege de rol die deze typen in een app spelen, zijn meestal representatief voor zelfstandige naamwoorden. Hier zijn enkele voorbeelden:
var scoreCounter voor een SpriteKit-spelstatusvariabele.laat sharedInstance voor een singleton.Gebruik van Booleaanse methoden en eigenschappen moet worden gelezen als beweringen over de ontvanger. - Appel
Door te zeggen dat booleans "beweringen over de ontvanger zouden moeten zijn", bedoelen we gewoon dat ze ja of nee verklaringen zouden moeten zijn. Laten we een paar voorbeelden bekijken:
var isEmpty voor een array.laat raken knip voor een sprite van een spel.Protocollen die beschrijven wat iets is moeten als zelfstandige naamwoorden worden gelezen. - Appel
Als u protocollen gebruikt om een "sjabloon" -type te maken, moet u dezelfde naam gebruiken als voor variabelen en constanten. Dit is ook logisch omdat je het type methoden, klassen, etc. noemt. Hier zijn een paar voorbeelden:
protocol Fruit voor verschillende soorten fruitklassen.protocol Collecties voor arrays, lijsten en meer.Protocollen die een mogelijkheid beschrijven, moeten worden benoemd met behulp van de achtervoegsels: mogelijk, bruikbaar of ing. - Appel
Als uw protocollen definiëren wat een type kan doen, moet dit een naam krijgen met de bovenstaande achtervoegsels. Dit moet worden gelezen alsof het protocol "in staat" is om iets te doen. Hier is nog een lijst met voorbeelden:
protocol Retourneerbaar voor typen die kunnen worden geretourneerd.protocol ProgressReporting voor typen die voortgang melden.Naast deze naamgevingsconventies beveelt Apple ook aan dat je 'termen van de kunst', of met andere woorden termen die niet gemakkelijk te begrijpen zijn, vermijdt. Ze zeggen niet om ze volledig te vermijden, maar gebruiken ze niet wanneer een basiswoord voldoende is.
In productieniveaus gebruiken ontwikkelaars ontwerppatronen om hun code te structureren op een manier die kan worden gewijzigd en die ook leesbaarder is. Laten we een paar ontwerppatronen bespreken die u kunt gebruiken in uw volgende iOS-app.
Hoe cliché dit ook klinkt, dit is echt de basis van hoe je je app programmeert. Laten we zeggen dat je een huis bouwt, je droomhuis. Dit huis is vijf verdiepingen hoog, dus als je geen sterke basis bouwt en de blauwdrukken volgt, zal het waarschijnlijk omvallen. De basis van een iOS-app is het ontwerppatroon of de patronen die u kiest. Laten we kijken naar twee van de meest gebruikte patronen.
Het Model-View-Controller of MVC-ontwerppatroon is een industriestandaard. Het scheidt elk deel van uw code in drie delen: het model, het aanzicht en de controller.
Er zijn veel variaties hiervan, zoals MVVM en MVP. Het is de moeite waard om ze te lezen,maar het principe is vergelijkbaar met MVC. Voor meer informatie over MVC en MVVM, bekijk deze artikelen van Bart Jacobs hier op Envato Tuts+.
Welke je ook kiest, ze worden allemaal ontwerppatronen genoemd en ze maken onze code modulair. Laten we kijken naar een ander ontwerppatroon dat een aanvulling kan zijn op het app-patroon dat u wilt gebruiken.
Een singleton is een enkele instantie van een klasse die te allen tijde in het geheugen aanwezig is. Dus waarom geven we hierom? Nou, laten we zeggen dat je een app bouwt die verbinding maakt met een database. U hebt een plaats nodig om al uw gegevensserviceverbindingen te plaatsen. Dit zou een perfecte plek zijn om singletons te gebruiken.
Kijk naar de onderstaande code - het laat je zien hoe je een singleton construeert:
// Declaration class DataService static var shared = DataService () func createUser () // Do something // Call-site DataService.shared.createUser ()
Het is zo makkelijk!
Als u ontwerppatronen gebruikt, zal uw code veel leesbaarder zijn, evenals georganiseerd en modulair, zodat u problemen met uw app veel gemakkelijker kunt isoleren en grote wijzigingen kunt aanbrengen met minimale herbedrading van de code.
Raadpleeg onze volledige cursus voor meer ontwerppatronen voor Swift.
In deze cursus leert u 21 verschillende ontwerppatronen. Misschien vindt u er wel een die de manier van coderen zal veranderen!
Zoals u kunt zien, is het niet zo moeilijk om uw code leesbaarder en overzichtelijker te maken. Wanneer u de moeite neemt om dit te doen, heeft u het voordeel van gemakkelijk te wijzigen code en kunt u uw code gemakkelijker maken voor anderen om ze te begrijpen. Werkgevers zoeken naar deze dingen, dus maak er een gewoonte van om deze tips regelmatig toe te passen!
Ik hoop dat je deze tutorial leuk vond, en terwijl je hier bent, bekijk enkele van onze andere tutorials over de ontwikkeling van Swift en iOS-apps..
