Scrivere codice morto è utile?

Trovi utile scrivere un codice morto?

Alcuni dicono "Se hai 2 logiche per fare qualche operazione, allora invece di fare commenti su altri codici logici o rimuovere codice, rendilo un codice morto perché non influirà sull'operazione."

Esempio:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

È vero?

Di solito non scrivo codici morti invece rimuovo solo la seconda logica.

IMO, è peggio che inutile.

Oltre ad essere una perdita di tempo, ti dà (o il prossimo) l'illusione di avere del codice che funzionerà se cambi truein false. È solo un'illusione ... a meno che tu non lo provi.

E, ovviamente, è il disordine che rende il codice più difficile da leggere.

Se si utilizza qualsiasi tipo di codice morto SCM è raramente utile. Dovresti invece eliminarlo e se hai mai bisogno di vedere il codice per la logica 2 lo recuperi dal repository SCM.

Modificare:

Se hai un codice morto e stai mantenendo altre parti del codice, potresti provare a ottenere usi di un codice che potrebbe far apparire il codice morto. Se qualcun altro sta facendo la manutenzione potrebbe non conoscere il suo codice effettivamente morto e anche se lo fanno, sicuramente non sapranno perché è ancora lì.

Se poi pensi che un metodo possa essere cancellato dal momento che non è usato dal codice "live" ma solo dal codice morto, dovresti cambiare (e molto probabilmente infrangere) il tuo codice morto o creare l'altro codice morto stesso.

Alla fine saresti sicuramente finito in una sorta di inferno di mantenimento.

Pertanto, il codice migliore è il codice eliminato, poiché non può produrre risultati errati o distrarre i manutentori. :)

No, è un male, perché ingombra il codice e riduce la manutenibilità.

Di solito, c'è una chiara ragione per preferire una delle "logiche" alternative. Questo motivo (e l'esistenza di un'alternativa rifiutata) dovrebbe essere documentato in un commento in codice. Nel caso relativamente improbabile in cui il motivo non sia più valido, il codice alternativo può essere recuperato dalla cronologia del repository (se era la soluzione implementata precedentemente preferita), oppure potenziato e implementato utilizzando le conoscenze e i requisiti attuali (se è solo un vago idea).

Non influisce sul funzionamento ma influisce sulla manutenzione. Si desidera mantenere il codice il più ordinato possibile per facilitarne la manutenzione.

Sono sinceramente confuso da quello che stai facendo.

In ordine di priorità decrescente:

1. Dovresti tenere un registro delle modifiche al codice da qualche parte, quindi se il nuovo codice non funziona, puoi confrontarle. Questo dovrebbe essere sempre nel controllo del codice sorgente. Presumo che tu lo faccia già. In caso contrario, fai tutto il possibile per ottenere QUALSIASI forma di controllo del codice sorgente. Se devi assolutamente farne a meno (e nella mia vita non ho mai sentito parlare di un'occasione in cui questa è una buona idea), almeno rendi facilmente accessibili i backup regolari dello stato della fonte.

2. Supponendo che stai facendo il n. 1, in modo da poter recuperare il codice morto se necessario, NON tenerlo nel codice live a lungo termine. Sarà solo fonte di confusione, aggiungere ulteriore complessità senza valore, richiedere manutenzione, uscire dalla sincronizzazione con il codice live e fuorviare le persone in futuro, ecc., Ecc.

3. Detto questo, ci sono situazioni specifiche in cui è ragionevole un passaggio in fase di compilazione tra due percorsi di codice. Mentre stai sviluppando il nuovo codice, e subito dopo, può essere conveninet avere entrambi, quindi puoi facilmente passare da uno all'altro. Se è probabile che si debba tornare indietro o aggiungere un'opzione di configurazione esterna, un if basato su una costante fornisce a questi un percorso di aggiornamento ragionevole. Quindi, come molte altre cose, se risolve un problema particolare, fallo. In caso contrario, evitarlo.

La ragione per cui presumo che Poeple lo faccia troppo è: dall'avere dubbi (spesso correttamente) che le persone leggeranno effettivamente la storia del controllo del codice sorgente se hanno un problema; dalla paura, il nuovo codice non funzionerà e desidererà un'opzione di inversione facile. Un compromesso per provare a soddisfare entrambi potrebbe essere quello di inserire un commento "Modificato per calcolare ... il (Data). In caso di problemi, vedere la versione precedente nel controllo del codice sorgente" o simile.

No, non è utile. Quel elseblocco non soddisfa alcuno scopo. Se non si è sicuri dell'implementazione da utilizzare, commentarla, creare classi separate o salvarla altrove. Inoltre, per lo più hai - o almeno dovresti avere - una cronologia locale o remota dei tuoi file sorgente.

Il codice morto dovrebbe essere rimosso dal compilatore se la condizione dipende da una costante di tempo di compilazione, quindi tecnicamente non farebbe male a tenerlo dentro. Comunque preferisco piuttosto commentarlo poiché ciò migliora la leggibilità del codice.

Se vuoi essere in grado di passare rapidamente tra due alternative di codice, puoi usare il seguente costrutto di commento conveniente:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

se rimuovi solo il primo /nella prima riga di commento diventa:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Con questo puoi alternare tra le alternative semplicemente aggiungendo o rimuovendo un singolo /nel codice.

All'inizio può sembrare un po 'strano, ma una volta che ti sarai abituato, lo riconoscerai facilmente come una sorta di modello.

Puoi anche concatenare questo e quindi passare più blocchi contemporaneamente con un solo carattere:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Non lo userei in questo modo ma funziona.

Ci sono alcune occasioni molto rare in cui il vecchio codice, e il fatto che sia stato sostituito, dovrebbe davvero rimanere nel codice sorgente in modo che i futuri programmatori vengano avvisati di qualcosa che è contro-intuitivo. Nel qual caso, c'è anche bisogno di una sorta di commento che spieghi perché è ancora lì e cosa è successo.

Come sempre, scrivere programmi facili da mantenere significa rendere le cose più chiare, non solo seguire regole rigide e veloci. Se lasciare il codice morto in rende più facile capire cosa sta succedendo, quindi lasciarlo dentro. In caso contrario, estrarlo.

Sarà ignorato dal compilatore. Tuttavia sono d'accordo con te e rimuoverei semplicemente la dichiarazione else. Supponendo che tu stia utilizzando il controllo versione, sarai comunque in grado di vedere il vecchio codice visualizzando la cronologia del file.

Questa è probabilmente un'opinione personale, ma trovo che il codice morto distragga quando si mantiene un pezzo di codice. Per ogni dato compito, hai sempre più di un modo per eseguirlo, quindi devi sceglierne uno. Fai le tue ricerche, valuta gli algoritmi e scegline uno. Successivamente, il codice non deve contenere metodi alternativi al suo interno.

Se ci sono due contendenti molto forti, scrivi una piccola nota sull'alternativa e incollala in un wiki del progetto, o da qualche altra parte che contenga la documentazione del progetto. Se lo desideri, puoi inserire un commento di una riga che fa riferimento a questo documento e delinea il motivo per cui potresti voler leggerlo.

Non riesco immediatamente a pensare a una situazione in cui ho trovato utile scrivere codice morto. Se ci sono algoritmi alternativi, allora:

• o mantieni l'uno più utile ed elimini l'altro,
• oppure gli algoritmi sono applicabili a circostanze diverse, quindi si mantengono entrambi e il condizionale identifica le circostanze quando si utilizza il primo algoritmo.

In entrambi i casi, si finisce con nessun codice morto.

Se non elimini o commenti il ​​tuo codice morto, dovrai mantenerlo per evitare errori del compilatore. È tempo sprecato. Eliminalo se hai un SCM.

NO

Alcuni programmatori usano questo stile come alternativa ai commenti e lo trovano elegante.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

La semplice risposta è un semplice no. Il codice morto attira confusione e si verificano opportunità di bug. Non appena si digita un carattere nel codice, c'è un rischio. Quindi non aggiungere altro.

Una volta che ho dovuto scrivere qualcosa di simile è stato un modo per aggirare un bug del compilatore, mi è stato persino consigliato dal fornitore del compilatore di usare questo lavoro in giro.

Verifichi il codice morto che scrivi? Fai qualcosa per confermare che probabilmente è buono? In caso contrario, liberarsene.

Per future modifiche al codice, verificherai che il codice morto funzioni ancora? In caso contrario, liberarsene.

Non vuoi codice errato nei tuoi programmi, anche se non viene utilizzato. Avendolo lì suggerisce che può essere utilizzato. Di solito non vuoi mantenere due versioni di codice se non le usi entrambe, perché è un lavoro extra e poiché sembra inutile la maggior parte delle persone non farà un buon lavoro sul codice morto.

Potrebbero esserci motivi per mantenere il codice commentato (o, in C o C ++, #ifdefil codice ed out), ma questo dovrebbe essere accompagnato da commenti sul perché è ancora lì e quale scopo serve.

Si noti che in Java non verrà nemmeno compilato, a causa del codice non raggiungibile:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Idealmente, se c'è qualcosa che non va nel tuo codice, vuoi trovarlo il prima possibile, piuttosto che lasciarlo andare alla produzione ed essere trovato dai tuoi utenti.

Se una classe di errore può essere trovata dal tuo compilatore, allora lascia che il compilatore la trovi. IMHO, quello che qualcuno sta facendo scrivendo codice morto nel modo che descrivi, sta tentando di aggirare quell'errore del compilatore, permettendo a tutti i problemi che potrebbe causare di essere emersi in fase di esecuzione.

Potresti sostenere che il codice morto non può essere raggiunto, quindi non può causare problemi, ma qualcosa può andare storto nei commenti, nelle parentesi graffe e nei rientri che potrebbero farlo accadere.

Il motivo per cui le persone commentano alcune vecchie logiche è perché hanno paura di apportare grandi modifiche al codice. E infatti, rendersi conto una settimana dopo che il vecchio codice era effettivamente corretto e ora devi scriverlo da zero è una cagna. Ma è a questo che serve il controllo del codice sorgente. Se decidi di cambiare un po 'di logica, non aver paura di perdere il codice attuale piuttosto funzionante. Rimuovilo e lascia che SVN / Git / TFS si occupino del controllo delle versioni.

Se non è così e hai appena prodotto due diversi pezzi di logica per fare qualcosa perché non ti importa di YAGNI o DRY, allora assicurati di metterlo in un posto dove le persone possano usarlo. Magari getta un modello di strategia lì se ne hai voglia. Basta non fare queste cose "se .. altro", è un cattivo design e un dolore da mantenere. Se pensi davvero che un certo codice abbia il diritto di esistere, assicurati di renderlo possibile utilizzarlo.

Un altro aspetto è che fondamentalmente la maggior parte dei programmatori professionisti concorda sul fatto che la dimensione del codice è nemica. Dai un'occhiata a questi post del blog: Il miglior codice non è affatto un codice di Jeff Atwood, il peggior nemico di Code di Steve Yegge, puoi trovare molto di più.

Le persone stanno facendo molte cose per mantenere il proprio codice conciso e impedire che la base di codice diventi troppo grande, spesso anche sacrificando le prestazioni (dove non importa molto). Quindi, pensi davvero che 100 righe di codice morto possano essere una buona cosa?

L'unico posto in cui ho visto che ciò è utile è nei casi in cui si desidera disabilitare rapidamente qualcosa e testare / riempire (supponiamo che il programma esegua i passaggi A, B, C - tutto impiega molto tempo. Durante il riempimento, è possibile scegliere di disabilitare B e C per ora accelerare se sai che non sono necessari).
Ma la verità è che in tutti i casi questo è molto confuso. E se vedi un utilizzo a lungo termine per il tuo codice di backfill, dovresti scrivere il tuo codice in modo tale che utilizzi config per scegliere una scelta invece di usare tali hack.
La mia rapida regola empirica è quella di non controllare mai questo tipo di codice. Se hai bisogno di un controllo checkin / versione, ciò significa che sarai in grado di tornare presto a questo, e che è sempre una brutta cosa alla luce dei cambiamenti dei requisiti.

In realtà, c'è un modo in cui è utile avere un codice "morto": quando vuoi che il tuo programma lanci un'enorme eccezione perché ha raggiunto qualcosa che non avrebbe mai dovuto accadere. Questo potrebbe essere un errore del compilatore o se qualcuno nella riga ha cambiato la logica nel test che stai utilizzando e l'ha rovinato. Ad ogni modo, il tuo "altro" invia fuochi d'artificio. In questo caso, ti consigliamo di scaricarlo per il rilascio.

È di vitale importanza che il messaggio di errore indichi qualcosa come "Panico: non dovremmo mai essere qui alla riga% d nel file% s" ...