Accentsconagua
Share
L'importanza della leggibilità del codice è spesso sottovalutata, specialmente quando si programma in un ambiente che enfatizza l'interfaccia utente e l'esperienza dell'utente. Se è vero che è estremamente importante creare un'app fantastica, è altrettanto importante poterlo modificare in futuro. Con il codice illeggibile, può essere molto più difficile risolvere bug, con innumerevoli ore di tentativi di trovare le linee corrette di codice e capire come funziona.
Qualsiasi pazzo può scrivere il codice che un computer può capire. I buoni programmatori scrivono il codice che gli umani possono capire. - Martin Fowler
Con questo in mente, iniziamo e impariamo alcuni modi per rendere il tuo codice più leggibile sia per te che per gli altri che potrebbero dover apportare modifiche in futuro.
Questo può sembrare un metodo ovvio per rendere il codice più leggibile, ma è spesso trascurato. Se stai scrivendo il codice Swift, è probabile che tu stia usando Xcode come compilatore, e convenientemente, si scopre che Xcode è pieno di funzionalità che aiutano a rendere il tuo codice più leggibile.
Il tipo di commento più utilizzato è un commento a riga singola. Molti di noi usano le due barre in avanti di fronte a una linea in modo che vengano ignorate dal compilatore, ma non dimenticare quanto sia utile per documentare il codice!
Come aggiornamento, ecco come fare un tradizionale commento a riga singola:
// calcola la media della media delle medie = (gradoA + gradoB + grado C) / 3.0
Per convenzione, il commento è al di sopra della linea che spiega in modo più dettagliato. Prova ad usare i tuoi commenti per aggiungere spiegazioni o approfondimenti sul tuo codice, oltre a descrivere semplicemente cosa fa la linea. Ad esempio, il seguente commento per il codice sopra non è utile, perché non aggiunge ulteriori spiegazioni oltre a ciò che è immediatamente evidente.
// somma i voti e dividi per 3
Potresti averlo usato Comando-Fai clic per ottenere ulteriori informazioni su una particolare variabile, classe o metodo, ma sapevi che puoi aggiungere informazioni come questa al tuo codice? Puoi! Per fare ciò, utilizzare una sintassi di commento a riga singola speciale come segue: tre barre, seguite da uno spazio e un trattino. Quindi aggiungi il nome dell'attributo (ad esempio, "parametro") e infine, digita la parola e quindi la sua definizione.
Ecco un esempio di sintassi rapida del commento di aiuto:
/// - parametro foobar: definizione di foo func foobar ()
Quando tu Comando-clic il foobar funzione ovunque sia usata, vedrai la sua definizione mostrata sotto parametri.
Un commento di tipo meno diffuso è un commento a blocchi. Questi commenti vengono in genere utilizzati per inserire le informazioni sulla licenza e le informazioni sul copyright nella parte superiore del file, ma possono anche essere utilizzati se è necessario scrivere più righe che spiegano il codice (sebbene sia una buona regola generale che se si richiedono così tante parole per spiega il tuo codice, probabilmente non è abbastanza leggibile).
Per fare un commento di blocco, inizia con una barra, un asterisco e poi il tuo codice. Una volta che sei pronto per terminare il commento, puoi semplicemente inserire un asterisco e poi un'altra barra in avanti.
Ecco un esempio di questo:
/ * Copyright (c) 2018, Vardhan Agrawal Tutti i diritti riservati. * /
Tornando alla documentazione della guida rapida, i commenti bloccati sono il modo corretto per creare una documentazione completa del codice all'interno di Xcode. Per questi, usa semplicemente due asterischi per iniziare e terminare come faresti per un normale commento di blocco con un singolo asterisco. È anche possibile utilizzare la sintassi del contrassegno per formattare il commento e renderlo più leggibile.
Questo è come si dovrebbe documentare un codice:
/ ** Questa funzione restituisce un elenco di casualità. ** Parametri: ** - foo: un po 'di casualità. - bar: un mucchio più casualità. * /
Inizia ad aggiungere commenti positivi al tuo codice e sarai un passo avanti verso la scrittura di codice leggibile.
Potresti aver sentito molto, ma il codice deve essere in grado di leggere come l'inglese. In realtà, al computer non importa un po 'come apparirà agli umani, ma uno dei segni di un buon programmatore è quanto possano articolare il loro codice per essere il più leggibile possibile.
In Swift, è meglio dare un nome alle cose in base al ruolo che l'oggetto riproduce nel codice. Ad esempio, invece di usare semplicemente il nome Mela per una variabile di tipo Mela, se la mela serve da cibo per un animale, potrebbe essere nominata cibo anziché.
A volte può essere una tentazione dare molte responsabilità a un oggetto che dovrebbe essere specializzato, e questo può rendere la tua app meno modulare e più confusa per chiunque stia leggendo il codice. Dare un nome ai tuoi oggetti basandoti su ciò che fanno può aiutarti a ricordare di dare solo ruoli agli oggetti di cui sono responsabili.
I nomi di ... proprietà, variabili e costanti dovrebbero essere letti come nomi. - Mela
Questa regola generale ha senso perché il ruolo giocato da questi tipi in un'app è tipicamente rappresentabile da nomi. Ecco alcuni esempi:
var scoreCounter per una variabile di stato del gioco SpriteKit.let sharedInstance per un singleton.Gli usi dei metodi e delle proprietà booleani dovrebbero essere letti come asserzioni sul ricevitore. - Mela
Dicendo che i booleani "dovrebbero essere asserzioni sul ricevente", intendiamo semplicemente che dovrebbero essere dichiarazioni sì o no. Diamo un'occhiata ad alcuni esempi:
var isEmpty per un array.lascia touchesEdge per uno sprite di giochi.I protocolli che descrivono ciò che qualcosa deve essere letto come nomi. - Mela
Se stai usando i protocolli per fare un tipo di "modello", dovresti usare la stessa denominazione che useresti per le variabili e le costanti. Questo ha senso anche perché stai nominando il tipo di metodi, classi, ecc. Ecco alcuni esempi:
protocollo di frutta per diversi tipi di classi di frutta.Collezioni di protocollo per matrici, elenchi e altro.I protocolli che descrivono una funzionalità dovrebbero essere nominati usando i suffissi: able, ible o ing. - Mela
Se i tuoi protocolli stanno definendo ciò che un tipo è in grado di fare, dovrebbe essere nominato con i suffissi sopra. Questo dovrebbe essere letto come se il protocollo fosse "in grado" di fare qualcosa. Ecco un altro elenco di esempi:
protocollo restituibile per i tipi che possono essere restituiti.protocollo ProgressReporting per i tipi che segnalano lo stato di avanzamento.Oltre a queste convenzioni di denominazione, Apple consiglia anche di evitare quelli che chiamano "termini d'arte" o, in altre parole, termini che potrebbero non essere facilmente comprensibili. Non dicono di evitarli completamente, ma non li usano quando invece basterà una parola di base.
Nelle app di produzione, gli sviluppatori utilizzano schemi di progettazione per strutturare il codice in un modo che può essere modificato ed è anche più leggibile. Discutiamo alcuni modelli di design che è possibile utilizzare nella prossima app iOS.
Come può sembrare un cliché, questo è davvero il fondamento di come si programma la tua app. Diciamo che stai costruendo una casa, la casa dei tuoi sogni. Questa casa è alta cinque piani, quindi se non costruisci una base solida e segui i progetti, probabilmente si rovescia. La base di un'app per iOS è il modello o i pattern di progettazione scelti. Diamo un'occhiata a due dei modelli più comunemente usati.
Il modello Model View Controller o MVC è uno standard del settore. Separa ogni parte del codice in tre parti: il modello, la vista e il controller.
Ci sono molte varianti di questo, come MVVM e MVP. Vale la pena leggerli,ma il principio è simile a MVC. Per ulteriori informazioni su MVC e MVVM, dai un'occhiata a questi articoli di Bart Jacobs qui su Envato Tuts+.
Qualunque cosa tu scelga, sono tutti chiamati modelli di design e rendono il nostro codice più modulare. Diamo un'occhiata a un altro modello di progettazione che può completare il modello di app che scegli di utilizzare.
Un singleton è una singola istanza di una classe che è presente in ogni momento in memoria. Allora perché ci importa di questo? Bene, diciamo che stai costruendo un'app che si connette a un database. Hai bisogno di un posto dove mettere tutte le tue connessioni al servizio dati. Questo sarebbe un posto perfetto per usare i singleton.
Guarda il codice qui sotto: ti mostrerà come costruire un singleton:
// Classe di dichiarazione DataService static var shared = DataService () func createUser () // Esegui qualcosa // Call-site DataService.shared.createUser ()
È così facile!
Se si utilizzano modelli di progettazione, il codice sarà molto più leggibile, nonché organizzato e modulare, in modo da poter isolare i problemi con l'app in modo molto più semplice e apportare grandi cambiamenti con il minimo ricablaggio del codice.
Per saperne di più modelli di design per Swift, consulta il nostro corso completo.
In questo corso imparerai 21 diversi modelli di design. Potresti trovarne uno che trasformerà il tuo modo di codificare!
Come puoi vedere, non è difficile rendere il tuo codice più leggibile e organizzato. Quando fai lo sforzo di farlo, avrai il vantaggio di un codice facile da modificare, oltre a rendere il tuo codice più facile da capire per gli altri. I datori di lavoro cercano queste cose, quindi prendi l'abitudine di applicare questi suggerimenti su base regolare!
Spero che questo tutorial ti sia piaciuto e, mentre sei qui, dai un'occhiata ad alcuni dei nostri altri tutorial sullo sviluppo di app Swift e iOS.
