Quanto duplicato di codice si fa a tollerare? [chiuso]

Question

In una revisione del codice recente ho notato qualche riga della logica duplicato in una classe (meno di 15 righe). Quando ho suggerito che l'autore refactoring del codice, ha sostenuto che il codice è più semplice da capire in questo modo. Dopo aver letto nuovamente il codice, devo convenire estrarre la logica duplicato avrebbe fatto male un po 'di leggibilità.

Lo so secco è linea guida, non è una regola assoluta. Ma in generale, siete disposti a ferire la leggibilità in nome della SECCO?

Answer 1

Refactoring: migliorare la progettazione del codice esistente

La Regola del Tre

  

La prima volta che si fa qualcosa,   fallo e basta. La seconda volta che fate
  qualcosa di simile, sussultare alla duplicazione, ma si fa il
duplicato   cosa comunque. La terza volta che si fa qualcosa di simile, si refactoring.

Tre scioperi e si refactoring.

---

codificatori sul luogo di lavoro

  

Seibel: Quindi, per ognuna di queste chiamate XII si sta scrivendo un   implementazione.
  Hai mai scopre che si stavano accumulando un sacco di   bit di codice molto simile?

     

Zawinski: Oh, sì, sicuramente. Solitamente dalla seconda o terza volta   hai tagliato e incollato
  quel pezzo di codice è come, bene, il tempo di fermarsi   tagliare e incollare e metterlo in un   subroutine.

Answer 2

tollero nessuno. Mi può finire per avere alcuni a causa di vincoli di tempo o quant'altro. Ma io ancora non ho trovato un caso in cui codice duplicato è davvero giustificata.

dicendo che farà male la leggibilità suggerisce solo che siete male a nomi di raccolta: -)

Answer 3

Personalmente, preferisco mantenere il codice comprensibile, prima di tutto.

asciutto è di circa facilitare il mantenimento in codice. Rendere il codice meno comprensibile al fine di rimuovere il codice ripetuto fa male la manutenibilità di più, in molti casi, di avere alcune linee ripetute di codice.

Detto questo, sono d'accordo che DRY è un buon obiettivo da seguire, quando si pratica.

Answer 4

Se il codice in questione ha una chiara attività o la tecnologia di supporto scopo P, si dovrebbe in genere refactoring. Altrimenti dovrete il problema classico con il codice clonato:. Alla fine scoprirete la necessità di modificare il codice di supporto P, e non troverete tutti i cloni che lo implementano

Alcune persone suggeriscono 3 o più copie è la soglia per il refactoring. Credo che se si hanno due, si dovrebbe fare così; trovando l'altro clone (s) [o anche sapendo che potrebbero esistere] in un grande sistema è difficile, se si dispone di due o tre o più.

Ora, questa risposta è fornita nel contesto di non avere strumenti per trovando i cloni. Se è possibile trovare in modo affidabile cloni, allora la ragione originale per refactoring (evitando errori di manutenzione) è inferiore persausive (l'utilità di avere un nome di astrazione è ancora reale). Che cosa si vuole veramente è un modo per trovare e tenere traccia cloni; astraendoli è un modo per garantire la si può "trovare" loro (facendo trovando banale).

Uno strumento che può trovare i cloni in modo affidabile può almeno impedire di fare errori di manutenzione fallimento-to-update-clone. Uno di questi strumenti (Sono l'autore) è il CloneDR . CloneDR trova cloni che usano la struttura langauge mirati come guida, e quindi trova cloni indipendentemente dal layout di spazi bianchi, i cambiamenti nei commenti, variabili, ecc (E 'implementato per un numero rinominato un lingue tra cui C, C ++, Java, C #, COBOL e PHP ). CloneDR troverà cloni attraverso sistemi di grandi dimensioni, senza che sia stata alcuna guida. cloni rilevati sono indicati, così come il antiunifier , che è essenzialmente l'astrazione si potrebbe avere scritto, invece. Le versioni di esso (per COBOL) ora si integrano con Eclipse, e si mostrano quando si modifica all'interno di un clone in un buffer, così come dove gli altri cloni sono, in modo che si può ispezionare / rivedere gli altri mentre siete lì. (Una cosa che si potrebbe fare è di refactoring:).

Ho usato pensare clonazione era solo a titolo definitivo sbagliato, ma la gente fanno perché non sanno come il clone varierà da quello originale e quindi l'astrazione finale non è chiaro al momento l'atto di clonazione si sta verificando. Ora io credo che la clonazione è buono, se è possibile tenere traccia dei cloni e si tenta di refactoring dopo l'astrazione diventa chiaro.

Answer 5

Non appena si ripete nulla che si sta creando più posti di avere apportare le modifiche se si scopre che hai fatto un errore, bisogna estenderlo, modificare, eliminare o qualsiasi altro del decine di altri motivi che potrebbero venire contro quella forza un cambiamento.

Nella maggior parte delle lingue, l'estrazione di un blocco a un metodo opportunamente chiamato raramente possono danneggiare la vostra leggibilità.

E 'il vostro codice, con i vostri standard, ma la mia risposta di base per il vostro "quanto?" è non ...

Answer 6

non hai detto che lingua, ma nella maggior parte dei IDE si tratta di una semplice Refactor -> Estrai metodo. Quanto più facile è che, e un unico metodo con alcuni argomenti è molto più gestibile di 2 blocchi di codice duplicato.

Answer 7

Molto difficile da dire in astratto. Ma la mia convinzione è che anche una sola riga di codice duplicato deve essere fatto in una funzione. Naturalmente, non sempre a raggiungere questo standard elevato me stesso.

Answer 8

refactoring può essere difficile, e questo dipende dalla lingua. Tutte le lingue hanno dei limiti, e, talvolta, una versione riscritta di logica duplicato può essere linguisticamente più complessa di quanto il codice ripetuto.

Spesso duplicazioni di codice LOGIC verificarsi quando due oggetti, con diverse classi di base, hanno somiglianze nel loro modo di operare. Ad esempio 2 componenti GUI che entrambi i valori di visualizzazione, ma non implementano un'interfaccia comune per l'accesso quel valore. Refactoring questo tipo di sistema o richiede metodi che assumono gli oggetti più generici di necessario, seguita da typechecking e la colata, oppure la gerarchia di classe deve essere ripensata e ristrutturata.

Questa situazione è diversa rispetto a quando il codice è stato esattamente duplicato. Io non necessariamente creare una nuova classe di interfaccia se solo intesa per essere usato due volte, ed entrambe le volte all'interno della stessa funzione.

Answer 9

Il punto di DRY è manutenibilità. Se il codice è più difficile da capire è più difficile da mantenere, quindi se fa male refactoring leggibilità si può effettivamente essere non aver rispettato l'obiettivo di A SECCO. Per meno di 15 righe di codice, sarei propenso a concordare con il vostro compagno di classe.

Answer 10

In generale, no. Non per la leggibilità in ogni caso. C'è sempre un modo per il refactoring del codice duplicato in un intento rivelare metodo comune che si legge come un libro, IMO.

Se si vuole fare un argomento per aver violato DRY al fine di evitare le dipendenze che introducono, che potrebbe portare più peso, e si può ottenere il parere supponente di Ayende insieme al codice per illustrare il punto qui .

A meno che il dev è in realtà Ayende anche se vorrei tenere stretto a secco e ottenere la leggibilità attraverso metodi intenzione rivelare.

BH

Answer 11

Accetto NO codice duplicato. Se si utilizza qualcosa in più di un luogo, sarà parte del quadro o almeno una libreria di utilità.

La migliore linea di codice è una riga di codice non scritto.

Answer 12

In realtà dipende da molti fattori, quanto viene utilizzato il codice, leggibilità, ecc In questo caso, se v'è solo una copia del codice ed è più facile da leggere in questo modo, allora forse è bene. Ma se è necessario utilizzare lo stesso codice in un terzo luogo vorrei prendere in seria considerazione il refactoring in una funzione comune.

Answer 13

La leggibilità è una delle cose più importanti codice può avere, e io sono disposto a compromessi su di esso. codice duplicato è un cattivo odore, non è un peccato mortale.

Detto questo, ci sono problemi qui.

Se questo codice dovrebbe essere lo stesso, piuttosto che per coincidenza è la stessa, c'è un rischio manutenibilità. Avrei commenti in ogni luogo indicando l'altro, e se aveva bisogno di essere in un terzo posto che avevo refactoring fuori. (Io in realtà hanno codice come questo, in due programmi diversi che non condividono i file di codice appropriato, quindi i commenti in ogni punto del programma ad un altro.)

Non hai detto che se le linee fanno un insieme coerente, l'esecuzione di qualche funzione si può facilmente descrivere. Se lo fanno, li refactoring fuori. Questo è improbabile che sia il caso, dal momento che l'utente accetta che il codice è più leggibile incorporato in due punti. Tuttavia, si potrebbe cercare una somiglianza più grande o più piccolo, e forse fattore una funzione per semplificare il codice. Solo perché una dozzina di righe di codice sono ripetute non significa che una funzione dovrebbe consistere che dozzina di linee e non di più.