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

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

ad es. 3 righe di codice in 1 riga.

Ho letto in Code Craft di Pete Goodliffe che la leggibilità è la chiave.

I vostri pensieri?

"Meno linee" non è sempre la stessa cosa di "più efficiente". Presumo tu intenda "Se un programma dovesse essere abbreviato a spese della leggibilità".

I programmi devono essere scritti per essere letti dalle persone e solo per inciso per l'esecuzione delle macchine.

-Abelson & Sussman, Struttura e interpretazione dei programmi per computer

In generale, penso che sia più importante che un programma sia facilmente comprensibile che essere breve. Dovrei notare, tuttavia, che accorciare un programma spesso lo rende anche più leggibile (c'è l'ovvia soglia a cui arrivi quando il tuo codice inizia a sembrare un rumore di linea, ma fino a quel momento, esprimere qualcosa in modo più succinto sembra renderlo più chiaro).

Esistono specifiche eccezioni (come i tuoi script di shell personali o uno dei codici di munging dei dati) che nessuno dovrà mai mantenere e solo tu avrai mai bisogno di leggere. In quella situazione, probabilmente va bene sacrificare un po 'di leggibilità per convenienza fintanto che puoi ancora capirla.

A Volte si.

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

Per un esempio di quest'ultimo, vedi l'articolo di Fast Inverse Square Root su Wikipedia.

In genere penso che sia meglio rendere prima leggibile qualcosa 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à è, secondo me, fuorviato.

L'unica volta in cui sacrificherei la leggibilità sarebbe quando il codice avrebbe mostrato un collo di bottiglia nelle prestazioni e una riscrittura lo avrebbe risolto. In tal caso, l' intenzione del codice deve essere ben documentata in modo tale che, in caso di bug, possa essere rintracciata più facilmente.

Ciò non significa che la riscrittura debba essere illeggibile ovviamente.

L'ho citato prima e lo citerò di nuovo:

Rendilo corretto,
chiariscilo,
rendilo conciso, rendilo
veloce.

In questo ordine.

Wes Dyer

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

In termini di codice, è sempre bello essere auto-documentati. Ma a volte non può succedere. A volte è necessario ottimizzare e talvolta quel codice non è di per sé molto leggibile.

Questo è ciò per cui sono stati inventati i commenti . Usali. Anche l'assemblaggio 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 succedendo aiutano sempre.

A mio avviso, non ci sono assolutamente scuse per non avere alcuni commenti di base. Chiaramente if ( x == 0 ) /* check if x is 0 */è totalmente inutile; non dovresti aggiungere rumore inutile 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 metriche, vero? - quella linea (e) di codice è l'attuale collo di bottiglia, quindi sì.

Altrimenti no: la leggibilità consentirà a te (o ad un altro) di poter modificare questo codice in un secondo momento per renderlo più efficiente, poiché è più facile da capire.

Nessuno vince Code Golf

ad es. 3 righe di codice in 1 riga

Un'idea particolarmente terribile.

Costo per giocare a golf - molto alto.

Costo per mantenere programmi illeggibili - astronomici.

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

Efficienza scelta con saggezza

Costo per scegliere l'algoritmo e la struttura dati corretti - moderato.

Costo per mantenere l'algoritmo e la struttura dati corretti - basso.

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

Foolish ("micro-ottimizzazione") Efficienza

Costo per giocare a micro-ottimizzazione - alto.

Costo per mantenere il codice illeggibile, micro-ottimizzato - molto elevato.

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

Dipende da se stiamo parlando di efficienza in termini di velocità di esecuzione del codice o efficienza in quanto lo sviluppatore può scrivere il codice. Se stai sacrificando la leggibilità del codice a favore della possibilità di digitare il codice molto velocemente, probabilmente ti ritroverai a pagare il tempo indietro in termini di debug.

Tuttavia, se stiamo parlando di sacrificare la leggibilità del codice in termini di velocità di esecuzione del codice, è probabilmente un compromesso accettabile a condizione che il codice debba preformarsi in modo efficiente. Scrivere qualcosa che corre il più velocemente possibile solo perché non puoi non è una buona ragione come perché è qualcosa come la radice quadrata inversa veloce in cui le prestazioni sono la chiave. Il trucco sta nel bilanciare il codice e assicurarsi che, anche se la fonte potrebbe essere difficile da leggere, i commenti che descrivono ciò che spiega spiegano cosa sta succedendo.

Molti trucchi, che avrebbero dovuto rendere il codice più veloce, ma tendono a renderlo meno leggibile, non sono più necessari, perché entrambi i compilatori sono diventati molto intelligenti (anche più intelligenti della maggior parte degli sviluppatori) o le macchine sono diventate ridicolmente veloci.

Non accetto l'argomento "leggibilità sulle prestazioni". Lascia che ti dia una risposta con una diversa rotazione.

Alcuni retroscena: sai cosa mi fa star male? Quando faccio doppio clic su Risorse del computer e devo effettivamente attendere che compaia. Se ciò richiede più di 5 secondi, sono davvero frustrato. La cosa stupida è, e non solo incolpare Microsoft per questo, è che in alcuni casi la ragione per cui ci vuole così tanto tempo è che bisogna prendere una decisione su quale icona mostrare! Giusto. Quindi eccomi qui seduto, interessato solo ad andare sul mio disco C: e devo aspettare che il driver acceda al mio CD-ROM e leggere l'icona da lì (supponendo che ci sia un CD nell'unità).

OK. Quindi, solo per un secondo, immagina tutti i livelli tra di me che fanno doppio clic su Risorse del computer e che in realtà parla tramite driver al CD-ROM. Ora immagina che ogni livello fosse ... più veloce ...

Vedete, dietro tutto ciò 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 semplicemente schifo (termine tecnico). E così dormi sonoro di notte dicendoti che hai fatto la cosa giusta assicurandoti che il codice sia più leggibile e tuttavia 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 righe debbano essere le migliori.

Ecco il mio approccio: in primo luogo, farlo funzionare, quindi farlo più veloce. Punta sempre a scrivere un codice efficiente e, se devi sacrificare la leggibilità, integralo con i commenti. Non sacrificherò l'efficienza in modo che un programmatore mediocre possa mantenerla. Spiegherò comunque il mio codice, ma se ciò non bastasse, mi dispiace, sei semplicemente incompetente a lavorare qui. Perché qui, scriviamo codice che è veloce e leggibile, e sebbene ci sia un equilibrio, il codice leggibile può essere spiegato mentre l'inefficienza è semplicemente inaccettabile.

Questa domanda mi è venuta spesso in mente quando si discutono interviste in ufficio. Molti anni fa, come laureato, mi è stata posta 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 via di mezzo. Il processo dovrebbe sopravvivere all'individuo in quanto le persone saranno più che vivaci che andranno e verranno e vorrete preparare i nuovi inizi il più presto possibile, e più facile è leggere il codice, più veloce è capire cosa sta succedendo.

Ho letto un libro un po 'di tempo fa abbastanza buono, chiamato Domain Driven Development: Domain-driven Design: Affrontare la complessità nel cuore del software Certo, all'inizio è un po' secco, ma il materiale è ben presentato. Questo dimostra un buon approccio che porta a sistemi che si documentano bene. La lingua è il mezzo per comunicare la tua soluzione, quindi più chiara è la soluzione, più facile è adattarsi se performace diventa un fattore citico. Questa è la mia convinzione e sembra aver funzionato bene per me.

Raramente ne varrebbe la pena il ROI nel rendere il codice più veloce a scapito della leggibilità. I computer moderni funzionano così velocemente che dubito che ci sarebbe uno scenario in cui lo vorresti. Se un computer esegue il codice, è necessario mantenerlo.

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

Un buon esempio è un nome di variabile: $a

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

Penso che ci sia buon senso qui.

Alcune applicazioni potrebbero giustificare una scorciatoia di bit-shift che non tutti capiranno, ma penso che ad un certo punto ci siano rendimenti ridotti e trovare uno scenario è raro *.

* questo dipende dall'industria e da altre cose del genere. Sto guardando questo dal punto di vista dello sviluppatore di software aziendale (Business Information Systems).

Per guardare questo da un'altra prospettiva (ma non per divagare), lavoro in un'azienda che fa SAAS. Quando un sito non funziona, dobbiamo risolverlo molto, molto velocemente - di solito qualcun altro sta riparando il codice di un altro sviluppatore.

Mi piacerebbe molto meglio qualcuno fare qualcosa di molto inefficiente, ma leggibile rispetto per renderlo fantasia e "veloce". I nostri server Web sono all'avanguardia e non è necessario consegnare una richiesta in milionesimi di secondo. Non abbiamo problemi di caricamento.

Quindi, in pratica, penso che tu abbia maggiori probabilità di ferire te stesso o gli altri ... (Preferirei che il mio weekend fosse tornato.)

Nella maggior parte dei casi, la risposta è "Affidati al tuo compilatore per fare il suo lavoro" e scrivi un codice leggibile. Ciò implica che il codice è strutturato in modo logico (cioè senza spaghetti) e auto-documentato (cioè, nomi sufficientemente chiari di variabili, funzioni, ecc.). Codice del supplemento che non è auto-documentato con commenti significativi. Non commentare per commentare, ad es.

x++; // Add one to x

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

Il codice pulito è un codice veloce. Scritto chiaramente, il codice facile da mantenere tende ad essere più veloce perché è un indicatore del fatto che il programmatore ha compreso l'attività a portata di mano e ha riformattato il codice fino al suo scopo principale.

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

Quando sto lavorando su qualcosa basato sulle prestazioni come la grafica, a volte sacrifico la leggibilità / manutenibilità quando sto facendo cose come l'elaborazione delle immagini quando sto lavorando sugli algoritmi nidificati più profondi in cui le piccole ottimizzazioni possono avere un effetto maggiore. E anche allora lo faccio solo dopo aver profilato per garantire che i cambiamenti accelerino effettivamente le cose. Non posso dirvi quante volte ho provato "ottimizzazioni" codificate a mano solo per scoprire che in realtà ha rallentato l'app a causa del modo in cui il compilatore ha ottimizzato il codice digitato a mano.

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

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

Come ha detto qualcun altro se ci sono aspetti "difficili da capire" di una soluzione, questo è ciò che serve ai commenti. L'ordine "corretto, leggibile, veloce" (o qualcosa del genere), che qualcun altro ha citato è solo una perdita di tempo.

Ho davvero difficoltà a credere che ci siano programmatori là fuori, che quando si presentano con un problema pensano nelle righe "... questo deve essere fatto in questo modo, ma farò in questo modo che è meno efficiente ma più leggibile / manutenibile e altre simili cazzate ... ". L'errore di questo è che il prossimo sviluppatore (vedendo le inefficienze) molto probabilmente modificherà il codice e il prossimo farà lo stesso e così via ... Il risultato finale è che dopo alcune versioni il codice diventerà quello che l'originale lo sviluppatore avrebbe dovuto scrivere al 1 ° posto. L'unica scusa per lo sviluppatore originale è a. non ci pensava (abbastanza onesto) e (come detto prima) b. vincoli di tempo e risorse.

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