Riduci al minimo gli effetti collaterali (idealmente non ne hai)
Una funzione che causa 3 cambiamenti in stati al di fuori del proprio ambito è molto più difficile da ragionare e mantenere rispetto a uno che semplicemente immette qualcosa e produce qualcos'altro. Non puoi semplicemente sapere cosa fa la funzione, devi ricordare cosa ha fatto e come ciò influisce su tutte le altre funzioni rilevanti.
Per OOP minimizzare gli effetti collaterali significa anche classi con un minor numero di membri, e in particolare un numero inferiore di membri che possono modificare lo stato della classe, poiché le funzioni membro possono modificare gli stati oltre i propri e avere effetti collaterali (possono manipolare gli interni della classe, ad es.). Significa anche classi con un minor numero di membri dei dati, in modo che ci sia meno stato per quei metodi da manomettere e meno effetti collaterali che possono causare.
Ad esempio, immagina di provare a progettare una struttura di dati elaborata in grado di mantenere uno sortedstato che utilizza per determinare se eseguire ricerche binarie o lineari. In tal caso, potrebbe essere utile separare il disegno in due classi. Chiamare sortedla classe non ordinata potrebbe quindi restituire una struttura di dati di un'altra classe che mantiene sempre i suoi contenuti ordinati. Ora hai meno effetti collaterali (quindi meno codice soggetto a errori e più facile da comprendere) e un codice più ampiamente applicabile (il primo progetto sarebbe dispendioso sia nell'elaborazione che nell'efficienza intellettuale umana per piccoli array che non devono mai essere ordinati).
Evitare dipendenze esterne superflue
Potresti essere in grado di implementare il codice più conciso che si possa immaginare con il massimo riutilizzo del codice utilizzando 13 librerie diverse per eseguire un'attività relativamente semplice. Tuttavia, ciò trasferisce un sovraccarico intellettuale ai tuoi lettori, costringendoli a comprendere almeno parti di 13 librerie diverse. Questa complessità intrinseca dovrebbe essere immediatamente apprezzata da chiunque abbia cercato di costruire e comprendere una libreria di terze parti che richiedesse il pull-in e la costruzione di una dozzina di altre librerie per funzionare.
Questa è probabilmente una visione molto controversa, ma preferirei una modesta duplicazione del codice all'estremo opposto, purché il risultato finale sia ben testato (niente di peggio del codice difettoso non testato duplicato più volte). Se la scelta è tra 3 righe di codice duplicato per calcolare un prodotto incrociato vettoriale o inserire una libreria matematica epica solo per radere via 3 righe di codice, suggerirei il primo a meno che l'intera squadra non sia a bordo con questa libreria matematica , a quel punto potresti considerare di scrivere solo 3 righe di codice anziché 1 se è abbastanza banale in cambio dei vantaggi del disaccoppiamento.
Il riutilizzo del codice è un atto di bilanciamento. Riutilizzi troppo e trasferisci la complessità intellettuale in un modo uno-a-molti, in quanto in quelle 3 righe di codice semplice che hai salvato sopra ha il costo di richiedere ai lettori e ai manutentori di comprendere molte più informazioni di 3 righe di codice . Inoltre, rende il codice meno stabile, poiché se la libreria matematica cambia, anche il codice potrebbe essere modificato. Riutilizzi troppo poco e moltiplichi anche il sovraccarico intellettuale e il tuo codice cessa di beneficiare di miglioramenti centrali, quindi è un atto di bilanciamento, ma l'idea che sia un atto di bilanciamento merita di essere menzionata dal momento che cercare di eliminare ogni piccola forma di duplicazione modesta può portare per un risultato difficile da mantenere, se non di più, dell'estremo opposto.
Metti alla prova la merda
Questo è un dato di fatto, ma se il tuo codice non gestisce tutti i casi di input e manca alcuni casi limite, come puoi aspettarti che gli altri mantengano il codice che hai scritto che non hai nemmeno ottenuto prima di trasferirlo ai loro occhi e mani? È abbastanza difficile apportare modifiche al codice che funziona perfettamente, per non parlare del codice che non era mai del tutto corretto in primo luogo.
Inoltre, il codice che supera i test approfonditi generalmente troverà meno motivi per cambiare. Ciò riguarda la stabilità che è ancora più un sacro graal da raggiungere rispetto alla manutenibilità, poiché il codice stabile che non deve mai essere modificato non comporta costi di manutenzione.
Documentazione dell'interfaccia
Dai la priorità a "cosa fanno le cose" rispetto a "come le fanno" se non puoi dedicare lo stesso tempo alla documentazione di entrambi. Un'interfaccia chiara che è ovvia nelle sue intenzioni su ciò che farà (o almeno ciò che dovrebbe fare) in tutti i possibili casi di input porterà una chiarezza di contesto alla propria implementazione che guiderà nella comprensione non solo di come per usare il codice, ma anche come funziona.
Nel frattempo il codice che manca di queste qualità in cui le persone non sanno nemmeno cosa dovrebbe fare è SOL, non importa quanto siano ben documentati i suoi dettagli di implementazione. Un manuale di 20 pagine su come viene implementato il codice sorgente è inutile per le persone che non riescono nemmeno a capire esattamente come dovrebbe essere usato in primo luogo e cosa dovrebbe persino fare in tutti i possibili scenari.
Per quanto riguarda l'implementazione, dai la priorità alla documentazione di ciò che fai diversamente dagli altri. Ad esempio, Intel ha una gerarchia di volumi limite per i suoi kernel raytracing. Dal momento che lavoro in questo campo, posso riconoscere la maggior parte di ciò che il loro codice sta facendo a colpo d'occhio senza setacciare la documentazione. Tuttavia, fanno qualcosa di unico che è l'idea di attraversare il BVH ed eseguire intersezioni in parallelo usando i pacchetti di raggi . È qui che voglio che diano la priorità alla loro documentazione perché quelle parti del codice sono esotiche e inusuali rispetto alla maggior parte delle implementazioni BVH storiche.
leggibilità
Questa parte è molto soggettiva. Non mi interessa molto della leggibilità di un genere vicino ai processi di pensiero umani. Il codice più ben documentato che descrive le cose al più alto livello è ancora difficile per me se l'autore utilizza processi di pensiero bizzarri e contorti per risolvere un problema. Nel frattempo il codice terse che usa nomi di 2 o 3 caratteri può spesso essere più facile per me capire se la logica è molto semplice. Immagino che potresti rivederti e vedere cosa preferiscono gli altri.
Sono principalmente interessato alla manutenibilità e, soprattutto, alla stabilità. Il codice che non trova motivi per cambiare è uno che non ha costi di manutenzione.