it-swarm.it

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

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

per esempio. 3 righe di codice in 1 riga.

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

I vostri pensieri?

40
TeaDrinkingGeek

"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 gli script Shell personali o uno dei codici di munging dei dati) che nessuno dovrà mai mantenere e solo tu dovrai mai leggere. In quella situazione, probabilmente va bene sacrificare un po 'di leggibilità per convenienza fintanto che puoi ancora capirla.

62
Inaimathi

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à 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 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) piuttosto che O(n)). la leggibilità solo per brevità è, secondo me, fuorviata.

30
Adam Lear

Ho citato prima , e lo citerò di nuovo:

Rendilo corretto,
chiariscilo,
rendilo conciso,
fallo veloce.

In questo ordine.

Wes Dyer

23
Benjol

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, il intenzione del codice deve essere ben documentato in modo che se c'è un bug, può essere rintracciato più facilmente.

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

22
ChrisF

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

In termini di codice, è sempre bello documentarsi da soli. 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'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 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.

9
user10197

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.

6
Klaim

Nessuno vince Code Golf

per esempio. 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.

4
S.Lott

Non accetto l'argomento "leggibilità rispetto alle 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: Per prima cosa, fallo funzionare, quindi rendilo più veloce.Sempre mira 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.

2
Maltrap

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 è un buon motivo come perché è qualcosa come radice quadrata inversa veloce dove le prestazioni sono la chiave. Il trucco consisterà 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.

2
rjzii

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' una lettura a 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.

2
Desolate Planet

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 ridicolmente veloci .

2

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 supponi 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.

molto piuttosto qualcuno farebbe qualcosa di molto inefficiente ma leggibile piuttosto che renderlo elegante 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 sia più probabile che tu faccia del male a te stesso o agli altri ... (Preferirei che il mio weekend fosse tornato.)

1
Frank V

Per la 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 è logicamente strutturato (cioè senza spaghetti) e autocompattante (cioè nomi sufficientemente chiari di variabili, funzioni, ecc.). Codice del supplemento che non è auto-documentato con commenti significativi. Non commentare per motivi di commento, 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.

1
Throwback1986

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 sul più profondo degli algoritmi nidificati in cui le piccole ottimizzazioni possono avere un effetto maggiore. E anche allora lo faccio solo dopo aver profilato per garantire le modifiche in realtà accelerare 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.

0
GrandmasterB