Dovresti sacrificare la leggibilità del codice con quanto sia efficiente il codice? [chiuso]

"Meno linee" non è sempre la stessa cosa di "più efficiente". Immagino tu voglia dire "Un programma dovrebbe essere più breve a scapito della leggibilità".

Programs must be written for people to read, and only incidentally for machines to execute.

-Abelson & Sussman, Structure and Interpretation of Computer Programs

In generale, penso che sia più importante capire facilmente un programma piuttosto che essere breve. Tuttavia, notare che rendere un programma più breve spesso lo rende anche più leggibile (c'è la soglia ovvia a cui si arriva quando il codice inizia a sembrare un rumore di linea, ma fino a quel punto, esprimere qualcosa in modo più sintetico sembra renderlo più chiaro).

Ci sono delle eccezioni specifiche (come i tuoi script di shell personali, o un codice di munging dei dati) che nessuno avrà mai bisogno di mantenere, e solo tu avrai mai bisogno di leggere. In questa situazione, probabilmente è giusto sacrificare la leggibilità per convenienza, purché tu possa ancora comprenderlo.

A volte sì.

La leggibilità è una buona cosa per cui lottare. La maggior parte del codice scritto per le tipiche applicazioni line-of-business sarà sufficientemente performante e l'attenzione alla leggibilità è importante. Nelle aree più impegnative in termini di prestazioni (come la programmazione di videogiochi o il calcolo pesante), potrebbe essere importante rinunciare alla leggibilità a favore dell'utilizzo di una particolare funzione linguistica che è orribilmente illeggibile e tuttavia incredibilmente performante.

Per un esempio di quest'ultimo, consulta l'articolo Root veloce inverso su Wikipedia.

In genere penso che sia meglio rendere qualcosa di leggibile prima e preoccuparsi delle prestazioni dopo, a condizione che vengano prese precauzioni di buon senso come non scegliere un algoritmo O (n ^ 2) su O (n). Sacrificare la leggibilità solo per brevità è, a mio avviso, fuorviato.

L'unica volta che avrei sacrificato la leggibilità sarebbe quando il codice è stato mostrato come un collo di bottiglia nelle prestazioni e una riscrittura lo avrebbe risolto. In tal caso l' intenzione del codice dovrebbe essere ben documentata in modo che, se c'è un bug, possa essere rintracciato più facilmente.

Questo non significa che la riscrittura debba essere illeggibile, naturalmente.

I l'ho citato prima , e lo citerò di nuovo:

Make it correct,
make it clear,
make it concise,
make it fast.

In that order.

Wes Dyer

Dovresti sacrificare la leggibilità del codice con quanto è efficiente il codice?

In termini di codice, è sempre bello essere autodocumentanti. Ma a volte ciò non può accadere. A volte è necessario ottimizzare e talvolta il codice non è di per sé molto leggibile.

Questo è stato il motivo per cui sono stati inventati i commenti . Usali. Anche l'assemblea ha commenti. Se hai scritto una massa di codice e non c'è un commento in vista, sono preoccupato. I commenti non influiscono sulle prestazioni del tempo di esecuzione, ma alcune note su ciò che sta accadendo aiuta sempre.

Nella mia mente non c'è assolutamente nessuna scusa per non avere alcuni commenti di base. Chiaramente if ( x == 0 ) /* check if x is 0 */ è totalmente inutile; non dovresti aggiungere rumore non necessario al codice, ma qualcosa del genere:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

È abbastanza utile.

Dovresti sacrificare la leggibilità del codice con quanto è efficiente il codice?

Se l'efficienza è il tuo obiettivo attuale (come nella fase di ottimizzazione) e sai - hai le metriche, vero? - quella linea (s) di codice è il collo di bottiglia attuale, quindi sì.

Altrimenti no: la leggibilità consentirà a te (oa un altro) di essere in grado di modificare questo codice in un secondo momento per renderlo più efficiente, in quanto è più facile da capire.

Nessuno vince Code Golf

e.g. 3 lines of code into 1 line

Un'idea particolarmente terribile.

Costo per giocare a golf con codice - molto alto.

Costo per mantenere i programmi illeggibili - astronomici.

Valore di questo tipo di codice minimizzato - zero. Funziona ancora, ma non funziona "meglio".

Wisely-Chosen Efficiency

Costo per scegliere il giusto algoritmo e la struttura dei dati - moderata.

Costo per mantenere il giusto algoritmo e la struttura dei dati - basso.

Valore dell'algoritmo e della struttura dati corretti - alto. L'utilizzo delle risorse è basso.

Foolish ("micro-optimization") Efficiency

Costo per giocare attorno alla micro-ottimizzazione - alta.

Costo per mantenere il codice illeggibile e micro-ottimizzato - molto alto.

Valore di micro-ottimizzazione - varia. Quando qui c'è un valore diverso da zero, i costi lo superano ancora.

Dipende se parliamo di efficienza in termini di velocità di esecuzione del codice o efficienza nella velocità con cui lo sviluppatore può scrivere il codice. Se stai sacrificando la leggibilità del codice a favore di poter digitare il codice molto velocemente, probabilmente ti ritrovi a pagare il tempo in fondo in termini di debugging.

Tuttavia, se stiamo parlando di sacrificare la leggibilità del codice in termini di velocità con cui il codice viene eseguito, è probabile che sia accettabile un compromesso purché il codice debba essere preformato in modo efficiente. Scrivere qualcosa che viene eseguito il più velocemente possibile solo perché è possibile non è quasi un buon motivo perché è qualcosa come veloce inverso radice quadrata dove la prestazione è la chiave. Il trucco sta nel bilanciando il codice e assicurandosi che anche se la sorgente potrebbe essere difficile da leggere, i commenti descrivono cosa spiega cosa sta succedendo.

Molti trucchi, che dovevano rendere il codice più veloce, ma tendono a rendere il codice meno leggibile, non sono più necessari, perché entrambi i compilatori è diventato molto intelligente (anche più intelligente della maggior parte degli sviluppatori) o le macchine sono diventate ridicole velocemente.

Non accetto l'argomento "leggibilità rispetto alle prestazioni". Permettimi di darti una risposta con una rotazione diversa.

Qualche background: sai cosa mi fa star male? Quando faccio doppio clic su Risorse del computer e devo effettivamente attendere che venga compilato. Se ciò richiede più di 5 secondi, mi sento davvero frustrato. La cosa stupida è, e non biasimare semplicemente Microsoft per questo, è che in alcuni casi il motivo per cui ci vuole così tanto tempo è che bisogna prendere una decisione su quale icona mostrare! Giusto. Quindi qui sono seduto, interessato solo ad andare al mio C: drive, e devo aspettare che il driver acceda al mio CD-ROM e legga l'icona da lì (supponendo che ci sia un CD nel lettore).

OK. Quindi, per un attimo, immagina tutti gli strati tra me facendo doppio clic su Risorse del computer e in realtà parlando tramite i driver al CD-ROM. Ora immagina che ogni livello fosse ... più veloce ...

Vedi, dietro tutto questo ci sono migliaia di programmatori felici perché il loro codice è "più leggibile". È fantastico. Sono felice per te. Ma dal punto di vista dell'utente, fa schifo (termine tecnico). E così dormi sano di notte dicendoti che hai fatto la cosa giusta assicurandoti che il codice sia più leggibile e più lento. Anche leggermente più lento di quanto possa essere. E così migliaia di sviluppatori lo fanno, e finiamo per aspettare i nostri PC a causa tua. Secondo me non sei degno. Non sto dicendo che le tue prime battute debbano essere le migliori.

Ecco il mio approccio: Per prima cosa, fallo funzionare, quindi rendilo più veloce. Sempre mira a scrivere codice efficiente e, se devi sacrificare la leggibilità, completalo con i commenti. Non sacrificherò l'efficienza in modo che qualche programmatore mediocre possa mantenerlo. Spiegherò comunque il mio codice, ma se ciò non bastasse, mi dispiace, sei semplicemente incompetente a lavorare qui. Perché qui, scriviamo il codice che è veloce e leggibile e, sebbene esista un equilibrio, è possibile spiegare il codice leggibile mentre l'inefficienza è inaccettabile.

Questa domanda mi è spesso venuta in mente quando le interviste sono state discusse in ufficio. Molti anni fa mi sono posto la domanda "Pensi che il codice sia auto-documentante?". Ora, dovevo rispondere a questa domanda come programmatore e per quanto riguarda l'intervistatore, era una domanda in bianco e nero, quindi non c'era una via di mezzo. Il processo dovrebbe sopravvivere all'individuale in quanto le persone diventeranno più che vivi e andranno a desiderare di avere nuove partenze il prima possibile, e più facile sarà leggere il codice, più veloce sarà capire cosa sta succedendo.

Ho letto un libro un po 'indietro che è stato abbastanza buono, chiamato Domain Driven Development: Progettazione basata sul dominio: affrontare la complessità nel cuore del software In effetti, all'inizio è un po 'una lettura asciutta, ma il materiale è ben presentato. Questo dimostra un buon approccio che porta a sistemi che si documentano bene. Il linguaggio è il mezzo per comunicare la tua soluzione, quindi più chiara è la soluzione, più è facile adattarsi se la performance diventa un fattore citico. Questa è la mia convinzione e sembra aver funzionato bene per me.

Raramente il ROI su come far funzionare il codice più velocemente a scapito della leggibilità può valerne la pena. I computer moderni funzionano così velocemente che dubito che ci sarebbe uno scenario in cui vorresti questo. Se un computer sta eseguendo il codice, tale codice deve essere mantenuto.

A tal fine, trovo la leggibilità molto importante. Naturalmente, come affermato numerose volte, solo perché il codice è leggibile non è necessario che sia più lento.

Un buon esempio è un nome di variabile: $a

Che cos'è $a ?? Questo è fuori dal contesto, quindi non puoi rispondere a questo, ma ti sei mai imbattuto in questo codice? Supponiamo che qualcuno abbia scritto $file_handle - ora cos'è? È chiaro anche fuori dal contesto. La lunghezza del nome della variabile fa una differenza insignificante al computer.

Penso che ci sia il buon senso da avere qui.

Alcune applicazioni potrebbero garantire una scorciatoia bit-shift che non tutti capiranno, ma penso che ad un certo punto ci siano rendimenti ridotti e la ricerca di uno scenario sia rara *.

* Questo dipende dall'industria e da altre cose simili. Sto osservando questo dal punto di vista degli sviluppatori di software aziendali (Business Information Systems).

Per guardare questo da un'altra prospettiva (ma non per divagare), lavoro in una società che fa SAAS. Quando un sito fallisce, dobbiamo sistemarlo davvero, molto velocemente - di solito qualcun altro sta aggiustando il codice di un altro sviluppatore.

Preferisco molto piuttosto che qualcuno faccia qualcosa di molto inefficiente ma leggibile piuttosto che renderlo elegante e "veloce". I nostri server web sono all'avanguardia e non è necessario fornire una richiesta in milionesimi di secondo. Non abbiamo problemi di caricamento.

Quindi, in pratica, penso che tu abbia più probabilità di farti del male o degli altri ... (preferirei riavere il mio weekend.)

Per la maggior parte dei casi, la risposta è "Fidati del tuo compilatore per fare il suo lavoro" e scrivi il codice che è leggibile. Ciò implica che il codice è strutturato logicamente (cioè senza spaghetti) e autodocumentante (cioè nomi sufficientemente chiari di variabili, funzioni, ecc.). Codice di supplemento che non è auto-documentato con commenti significativi. Non commentare per il gusto di commentare, cioè,

x++; // Add one to x

Piuttosto, commenta per te, il lettore, in 6 mesi o 12 mesi o in un altro tempo sufficientemente lungo. Adotta uno standard di codifica e seguilo.

Il codice pulito è un codice veloce. Il codice scritto in modo chiaro e di facile manutenzione tende ad essere più veloce perché è un indicatore del fatto che il programmatore ha compreso l'attività in corso e ha rifatto il codice al suo scopo principale.

Inoltre, i compilatori moderni ottimizzano le istruzioni in modo molto efficace. Quante linee di codice digitate per fare qualcosa e ciò che il compilatore crea in termini di istruzioni non sono necessariamente correlate. Leggi su compilatori per capire perché questo è il caso.

Quando sto lavorando a qualcosa di basato sulla performance come la grafica, occasionalmente sacrificherò la leggibilità / manutenibilità quando sto facendo cose come l'elaborazione delle immagini quando sto lavorando sugli algoritmi annidati più profondi dove piccole ottimizzazioni possono avere un effetto principale. E anche allora lo faccio solo dopo la profilazione per garantire che le modifiche effettivamente acceleri. Non posso dirvi quante volte ho provato le "ottimizzazioni" codificate a mano solo per scoprire che in realtà rallentava l'app a causa del modo in cui il compilatore ottimizzava il codice digitato a mano.

La leggibilità è una scusa per incompetenti e amp; programmatori pigri (in realtà lo stesso vale per "semplicità" quando usato come argomento per difendere un algoritmo / design scadente)!

Per ogni problema dato dovresti cercare la soluzione ottimale! Il fatto che i computer oggi siano veloci non è una scusa per sprecare cicli di CPU. L'unico vincolo dovrebbe essere "il tempo di consegnare". Nota che la "soluzione ottimale" qui indica quella che TU puoi inventare (non tutti possiamo trovare la soluzione migliore o avere l'abilità / le conoscenze per implementarle).

Come qualcun altro ha menzionato se ci sono aspetti "difficili da capire" di una soluzione, ecco a cosa servono i commenti. L'ordine "corretto, leggibile, veloce" (o qualcosa del genere), che qualcun altro ha menzionato è solo una perdita di tempo.

Ho davvero difficoltà a credere che ci siano programmatori là fuori, che quando vengono presentati con un problema pensano nelle righe "... questo deve essere fatto in questo modo ma farò in modo che sia meno efficiente ma più leggibile / manutenibile e altre schifezze ... ". L'errore di questo è che il prossimo sviluppatore (vedendo le inefficienze) probabilmente modificherà il codice e il prossimo farà lo stesso e così via ... Il risultato finale è che dopo alcune versioni il codice diventerà quello originale lo sviluppatore dovrebbe aver scritto nel 1 ° posto. L'unica scusa per lo sviluppatore originale è a. lui / lei non ci ha pensato (abbastanza giusto) e (come detto prima) b. tempo e amp; vincoli di risorse.

se la riduzione della leggibilità aiuta a codificare le prestazioni / l'ottimizzazione (come in swfobject e altre librerie js) è una ragione per continuare a scrivere codice ben formato e chiaramente leggibile e convertirlo in illeggibile / ottimizzato come parte del processo di "compilazione" / rilascio.