È meglio chiamare una funzione che non ha effetto a quel punto, SE migliora la chiarezza del codice?

60

Ho tre visualizzazioni nel mio programma (app iOS). Solo uno di essi è mai attivo contemporaneamente, quindi disattivo la visibilità per due di essi e cambio visibilità mentre l'utente preme i pulsanti. Le viste sono inizializzate come visibili, quindi ho disattivato la visibilità nel codice prima della visualizzazione della vista principale.

posso fare

[view1 setAlpha:0.0f];
[view2 setAlpha:0.0f];

per due delle visualizzazioni, ma ora la terza (quella che dovrebbe essere visibile all'avvio dell'app) non è indirizzata. Ho messo un

[view3 setAlpha:1.0f];

dopo i primi due, perché penso che chiarisca che ci sono in realtà tre viste, non due come si potrebbe pensare quando si vede il codice. Come lo fanno gli altri programmatori? È puramente una preferenza o ci sono delle convenzioni?

Se la chiamata è molto pesante, è ovviamente meglio non chiamarla quando non è necessario, ma mi chiedevo piccole cose come il mio esempio.

coding-style clean-code

— Kevin
fonte

134

Hai un invariante:

È sempre attiva (e visibile) una sola vista (su 3).

Quindi, ti suggerisco di fornire una funzione per cambiare contemporaneamente l'attività e la visibilità di TUTTE le viste:

[setActiveView viewID:2]

Questa funzione:

controlla se la vista è già attiva, evitando lavori inutili
imposta la vista come attiva e visibile
imposta le altre 2 viste come inattive e invisibili

Presenta molteplici vantaggi rispetto a una chiamata non elaborata a setVisibility:

amichevole: chiamarlo inutilmente non crea un problema di prestazioni
difensiva: il suo singolo parametro è molto più difficile da abbattere, mentre per setVisibilityè più difficile ricordare che l'intervallo di valori è 0.0f - 1.0fe che solo uno deve essere impostato su1.0f
resiliente: il prossimo non può dimenticare accidentalmente una delle opinioni
adattabile: l'aggiunta / rimozione di una vista non richiede lo scrutinio di tutto il codice dell'applicazione per trovare dove si trovano gli switch, una singola funzione (questa) deve essere aggiornata

Idealmente, per aiutare a far rispettare l'invariante, nessun'altra funzione dovrebbe essere in grado di sbagliare con questa impostazione ...

— Matthieu M.
fonte

Ottimo consiglio Lo farò con il mio esempio attuale. Ma che dire quando un tale progetto non è possibile / voluto? O decidi sul posto quale sia il modo migliore per gestirlo?

— Kevin,

4

@Kevin: dipende davvero. A volte puoi risolvere il problema ripetendo una raccolta, a volte no, ma il principio chiave è evitare la duplicazione e rendere facile la conservazione degli invarianti. Più azioni "manuali" devono essere ricordate affinché le cose funzionino correttamente, minori sono le possibilità che le cose funzionino correttamente. Odio essere vago qui, ma ci sono così tante diverse situazioni che temo che una regola "generica" ti porterebbe fuori strada.

— Matthieu M.,

23

"Rendere facile la preservazione degli invarianti" è una regola generica che vale la pena ricordare.

— Gusdor,

1

@Tonny: non so se incoraggiare l'uso di una variabile globale sia "farlo bene", ma in effetti se sai esattamente quale era attivo prima, devi solo aggiornare due viste. Un'altra soluzione è che ogni vista ricordi la sua visibilità e setVisibilitynon fare nulla se la visibilità è già quella richiesta, il che riduce la responsabilità.

— Matthieu M.,

1

@MatthieuM. Ho scritto in fretta, ma in realtà è quello che volevo dire anche io. Se conosci lo stato precedente devi solo aggiornare 2 view al massimo. Come ricordare che lo stato è un'altra questione ;-). Per quanto riguarda lo spostamento della responsabilità verso il basso: se la classe di visualizzazione non lo prevede, è necessario avvolgere la classe in un altro oggetto solo per aggiungere quella proprietà. Questa è una soluzione pulita, ma forse un po 'eccessiva.

— Tonny,

12

Idea alternativa: se il tuo obiettivo è prevenire il verificarsi di bug perché le persone dimenticano che ci sono tre punti di vista e fanno qualcosa con solo due di loro che dovrebbero davvero fare con tutti loro, quindi fai una funzione che rende impossibile dimenticare:

setViewVisibilities(0.0f, 0.0f, 1.0f)

Ora hai qualcosa di molto più potente: il tempo di compilazione ti garantisce di non aver dimenticato . Se dimentichi un parametro, il compilatore ti urlerà contro. Questo è molto più utile dei commenti o del codice non necessario, in quanto crea un protocollo con nome rigoroso che impone la proprietà che ti interessa.

Nel caso in cui view3non sia necessario modificare la visibilità, è possibile aggiungere un comportamento in cui passare un valore speciale come -1.0o nilo qualcosa lungo queste linee significa "non modificare affatto la visibilità della vista". Ciò aggira il problema di impostare inutilmente le visibilità.

— Jack
fonte

9

Se OP ottiene più di 10 visualizzazioni, diventa impossibile mantenere un parametro per visualizzazione. Il tuo punto sugli errori in fase di compilazione è corretto, ma questa è purtroppo una soluzione non mantenibile.

— Chris Cirefice,

3

@ChrisCirefice: se il numero di visualizzazioni aumenta, è possibile creare una sorta di oggetto / classe "ViewState", che applica questo invariante. Quindi usalo per cambiare ecc. Con così tante viste, qualche tipo di oggetto gestore probabilmente ha comunque senso.

— sleske,

8

Credo che l'aggiunta di un commento che spieghi che la chiamata non è necessaria (e perché) sia la cosa migliore.

^{(forse, il fatto che una chiamata non sia necessaria o che tu abbia bisogno di un commento a riguardo, potrebbe essere un odore di codice)}

— Basile Starynkevitch
fonte

1

@Niall Se possibile, un'asserzione sarebbe persino meglio di un commento.

— 200_successo

9

I commenti non sono la soluzione al codice non

— mantenibile

2

@Kevin o potresti scrivere un codice perfettamente leggibile senza commenti.

— Jan

1

@Jan I commenti non sono solo una spiegazione del codice .......

— Kevin,

2

@Kevin Direi che non dovrebbero mai esistere commenti per spiegare cosa fa il codice, ma piuttosto per spiegare perché lo sta facendo. E in tali situazioni spesso un refattore otterrà l'intento senza bisogno del commento (che sembra il punto di Jan).

— RJFalconer,

4

In questo caso particolare, @Mattieu M. ha la soluzione giusta.

Nel caso più generale, dove non esiste una trasformazione simile, devi chiederti: c'è qualche possibilità che un futuro programmatore possa rovinare tutto questo?

La risposta è generalmente sì. Il che significa, sì, è necessario aggiungere la chiamata. Forse alcune versioni future del framework iniziano con tutte le viste OFF anziché ON.

— Stig Hemmer
fonte