Accentsconagua
Share
Importanța lizibilității codului este adesea subestimată, în special atunci când se programează într-un mediu care pune accentul pe interfața utilizatorului și experiența utilizatorilor. Deși este adevărat că este extrem de important să faci o aplicație grozavă, este la fel de important să o poți schimba în viitor. Cu un cod care nu poate fi citit, poate fi mult mai greu să rezolvi bug-uri, cu nenumărate ore de încercare de a găsi liniile corecte de cod și de a înțelege cum funcționează.
Orice prost poate scrie codul pe care îl poate înțelege un computer. Programatorii buni scriu codul pe care oamenii îl pot înțelege. - Martin Fowler
Având în vedere acest lucru, să începem și să învățăm câteva modalități de a vă face codul mai ușor de citit atât pentru dvs., cât și pentru alții care ar putea fi nevoiți să facă modificări în viitor.
Aceasta poate părea o metodă evidentă de a face codul mai ușor de citit, dar este adesea trecute cu vederea. Dacă scrieți cod Swift, probabil că utilizați Xcode ca un compilator și, convenabil, se pare că Xcode este împachetat cu funcții care vă ajută să vă faceți mai ușor codul.
Cel mai utilizat tip de comentariu este un comentariu de o singură linie. Mulți dintre noi folosesc cele două ștanguri din față în fața unei linii, astfel încât acestea să fie ignorate de compilator, dar nu uitați cât de util este pentru a vă documenta codul!
Ca o reîmprospătare, iată cum să faceți un comentariu tradițional cu o singură linie:
// se calculează gradul mediu lasă media = (gradeA + gradeB + gradeC) / 3.0
Prin convenție, comentariul este deasupra liniei pe care o explică în detaliu. Încercați să utilizați comentariile dvs. pentru a adăuga explicații sau informații în codul dvs., dincolo de descrierea exactă a ceea ce face linia. De exemplu, următorul comentariu pentru codul de mai sus nu este util, deoarece nu adaugă nici o explicație suplimentară dincolo de ceea ce este imediat evident.
// înscrie gradele și divide cu 3
Probabil ați folosit Command-Click pentru a obține mai multe informații despre o anumită variabilă, clasă sau metodă, dar știați că puteți adăuga informații de genul acesta la propriul cod? Poti! Pentru a face acest lucru, utilizați o sintaxă specială de comentariu cu o singură linie după cum urmează: trei tăieturi, urmate de un spațiu și o linie. Apoi, adăugați numele atributului (de exemplu, "parametru") și, în final, tastați cuvântul și apoi definiția acestuia.
Iată un exemplu de sintaxă de comentariu rapid de ajutor:
/// - parametrul foobar: definirea foo func foobar ()
Cand tu Command-clic foobar funcția oriunde este utilizată, veți vedea definiția acesteia aflată sub parametrii.
Un tip de comentariu mai puțin utilizat pe scară largă este un comentariu bloc. Aceste comentarii sunt folosite în mod obișnuit pentru a plasa informații de licențiere și informații privind drepturile de autor în partea de sus a fișierului, dar ele pot fi de asemenea utilizate dacă aveți nevoie de scrierea mai multor rânduri care explică codul dvs. (deși este o regulă bună ca dacă aveți nevoie de multe cuvinte explicați-vă codul, probabil că nu este suficient de citit).
Pentru a face un comentariu bloc, începeți cu un slash înainte, un asterisc și apoi codul. Odată ce sunteți gata să încheiați comentariul, puteți plasa pur și simplu un asterisc și apoi o altă tăietură înainte.
Iată un exemplu:
/ * Drepturi de autor (c) 2018, Vardhan Agrawal Toate drepturile rezervate. * /
Revenind la documentația de ajutor rapid, blocați comentariile reprezintă modalitatea corectă de a crea documentația completă a codului în cadrul Xcode. Pentru acestea, pur și simplu utilizați două asteriscuri pentru a începe și a termina ca pentru un comentariu de bloc obișnuit cu un singur asterisc. Puteți chiar utiliza sintaxa de marcare pentru a formata comentariul dvs. și pentru ao face mai ușor de citit.
Acesta este modul în care ați documenta un cod:
/ ** Această funcție returnează o listă de aleatorie. ** Parametri: ** - foo: un pic de aleatorie. - bar: o ciudățenie mai aleatorie. * /
Începeți să adăugați comentarii bune la codul dvs. și veți fi cu un pas mai aproape de scrierea codului lizibil.
Este posibil să fi auzit acest lucru foarte mult, dar codul trebuie să poată citi ca și engleza. De fapt, computerul nu-i pasa un pic despre modul in care arata oamenilor, dar unul dintre semnele unui programator bun este cat de bine pot sa-si articuleze codul pentru a fi cat mai lizibil posibil.
În Swift, cel mai bine este să denumiți lucrurile pe baza rolului pe care îl joacă obiectul în cod. De exemplu, în loc să utilizați pur și simplu numele măr pentru o variabilă de tip măr, dacă mărul serveste ca hrană pentru un animal, ar putea fi numit alimente in schimb.
Uneori este tentant să dai multe responsabilități unui obiect care ar trebui să fie specializat și acest lucru poate face aplicația dvs. mai puțin modulară și mai confuză pentru oricine citește codul. Denumirea obiectelor pe baza a ceea ce fac ei poate ajuta să vă reamintesc să dați roluri numai obiectelor pentru care sunt responsabile.
Numele ... proprietăților, variabilelor și constantelor ar trebui citite ca substantive. - Măr
Această regulă generală degetului mare are sens din cauza rolului pe care aceste tipuri îl joacă într-o aplicație sunt reprezentate de obicei de substantive. Aici sunt cateva exemple:
var scoreCounter pentru o variabilă de stare a jocului SpriteKit.lăsați sharedInstance pentru un singleton.Utilizările metodelor și proprietăților booleene ar trebui citite ca afirmații despre receptor. - Măr
Afirmând că booleanul "ar trebui să fie afirmații despre receptor", înseamnă pur și simplu că ar trebui să fie declarații da sau nu. Să aruncăm o privire la câteva exemple:
var isEmpty pentru o matrice.să atingeEdge pentru un sprite de joc.Protocoalele care descriu ce este ceva ar trebui citite ca substantive. - Măr
Dacă utilizați protocoale pentru a crea un tip de "șablon", ar trebui să utilizați aceeași denumire pe care ați folosi-o pentru variabile și constante. Acest lucru are sens și pentru că numiți tipul de metode, clase etc. Aici sunt câteva exemple:
Fructe de protocol pentru diferite tipuri de clase de fructe.protocoale pentru tablouri, liste și multe altele.Protocoalele care descriu o capacitate ar trebui să fie numite folosind sufixele: capabile, ible sau ing. - Măr
Dacă protocoalele vă definesc ce tip poate să facă, acesta trebuie denumit cu sufixele de mai sus. Acest lucru ar trebui citit ca și cum protocolul este capabil să facă ceva. Iată o altă listă de exemple:
Protocol returnabil pentru tipurile care pot fi returnate.protocol ProgressReporting pentru tipurile care raportează progresul.În plus față de aceste convenții de numire, Apple recomandă, de asemenea, să evitați ceea ce ei numesc "termeni de artă" sau, cu alte cuvinte, termeni care nu pot fi ușor de înțeles. Ei nu spun să le evite complet, dar nu le folosiți când un cuvânt de bază va fi suficient.
În aplicațiile de producție, dezvoltatorii folosesc modele de design pentru a-și structura codul într-un mod care poate fi modificat și este, de asemenea, mai ușor de citit. Să discutăm câteva modele de design pe care le puteți utiliza în următoarea aplicație iOS.
Deoarece cliché-ul poate suna, acest lucru este într-adevăr fundamentul modului în care programați aplicația dvs. Să presupunem că construiți o casă, casa dvs. de vis. Această casă are o înălțime de cinci etaje, deci, dacă nu construiți o fundație solidă și nu urmați planurile, probabil că va fi răsturnată. Fundația unei aplicații iOS este modelul sau modelele pe care le alegeți. Să ne uităm la două dintre cele mai utilizate modele.
Modelul-View-Controller sau modelul de design MVC este un standard industrial. Se separă fiecare parte a codului dvs. în trei părți: modelul, vizualizarea și controlerul.
Există numeroase variații, cum ar fi MVVM și MVP. Merită să le citiți,dar principiul este similar cu MVC. Pentru mai multe despre MVC și MVVM, aruncați o privire aceste articole de Bart Jacobs aici pe Envato Tuts+.
Indiferent care dintre ele alegeți, toate se numesc modele de design și fac codul nostru mai modular. Să ne uităm la un alt model de design care poate completa modelul de aplicație pe care îl alegeți să îl utilizați.
Un singur ton este o singură instanță a unei clase care este prezentă în orice moment în memorie. De ce ne pasă de asta? Să presupunem că construiți o aplicație care se conectează la o bază de date. Aveți nevoie de un loc pentru a pune toate conexiunile de servicii de date. Ar fi un loc perfect pentru a folosi singleturi.
Uitați-vă la codul de mai jos - vă va arăta cum să construiți un singleton:
// Clasa de declarare DataService static var shared = DataService () func createUser () // Do ceva // DataService.shared.createUser ()
Este atât de ușor!
Dacă utilizați modele de design, codul dvs. va fi mult mai ușor de citit, organizat și modular, astfel încât să puteți izola problemele cu aplicația dvs. mult mai ușor și să efectuați modificări mari prin reeșiere minimă a codului.
Pentru a afla mai multe modele de design pentru Swift, verificați cursul nostru complet.
În acest curs veți învăța 21 de modele diferite de design. S-ar putea să găsiți unul care va transforma modul în care codificați!
După cum puteți vedea, nu este atât de greu să vă faceți codul mai ușor de citit și organizat. Când depui efortul de a face acest lucru, veți beneficia de codul ușor de modificat, precum și de a face codul dvs. mai ușor pentru alții să înțeleagă. Angajatorii caută aceste lucruri, așa că obișnuiți să aplicați aceste sfaturi în mod regulat!
Sper că vă place acest tutorial și, în timp ce sunteți aici, verificați câteva din celelalte tutoriale ale noastre despre dezvoltarea aplicațiilor Swift și iOS.
