Trovi utile scrivere codice morto?
Alcuni dicono "Se hai 2 elementi logici per fare qualche operazione allora invece di fare altro codice di logica commentato o rimuovendo il codice rendilo codice morto in quanto non influenzerà l'operazione."
Esempio: -
if(true){
// logic - 1
} else {
// logic - 2 // dead code
}
È vero?
Di solito non scrivo codici morti, ma rimuovo solo la seconda logica.
IMO, è peggio che inutile.
Oltre ad essere una perdita di tempo, ti dà (o il prossimo ragazzo) l'illusione di avere un codice che funzioni se cambi true in false . È solo un'illusione ... a meno che non lo provi.
E se naturalmente, è una confusione che rende il codice più difficile da leggere.
Se si utilizza qualsiasi tipo di codice morto SCM è raramente utile. Dovresti eliminarlo e se hai mai bisogno di vedere il codice per la logica 2 lo recuperi dal repository SCM.
Modifica:
Se hai un codice morto e stai manipolando altre parti del codice, potresti provare a utilizzare 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 si pensa che un metodo potrebbe essere cancellato poiché non viene usato dal codice "live" ma solo da un codice morto, si dovrebbe cambiare (e molto probabilmente si interrompe) il codice morto o rendere morto l'altro metodo codice stesso.
Alla fine ti ritroverai sicuramente in qualche forma di inferno di mantenimento.
Quindi, il codice migliore viene cancellato dal codice, poiché non può produrre risultati errati o distrarre i manutentori. :)
No, non va bene, perché ingombra il codice e riduce la manutenibilità.
Di solito, c'è una ragione chiara per preferire una delle "logiche" alternative. Questo motivo (e l'esistenza di un'alternativa rifiutata) dovrebbe essere documentato in un commento di codice. Nell'evento relativamente improbabile che la ragione non sia più valida, il codice alternativo può essere recuperato dalla cronologia del repository (se era la soluzione implementata precedentemente preferita), o implementato e implementato utilizzando le conoscenze e i requisiti attuali (se è solo un vago idea).
Non influenza il funzionamento ma influisce sulla manutenzione. Vuoi mantenere il codice il più ordinato possibile per semplificare la manutenzione.
Sono sinceramente confuso da quello che stai facendo.
In ordine di priorità decrescente:
Dovresti tenere un registro delle modifiche al codice da qualche parte , quindi se il nuovo codice non funziona, puoi confrontarle. Questo dovrebbe sempre essere nel controllo del codice sorgente. Presumo che tu lo faccia già. In caso contrario, fare tutto il possibile per ottenere una forma di controllo del codice sorgente. Se devi assolutamente fare a meno (e non ho mai sentito nella mia vita di un'occasione in cui questa è una buona idea), almeno rendere facilmente accessibili i backup regolari dello stato della fonte.
Supponendo che stai facendo # 1, quindi puoi recuperare il codice morto se necessario, NON tenerlo nel codice live a lungo termine. Sarà solo confusionario, aggiungere complessità extra senza alcun valore, richiedere manutenzione, uscire dalla sincronizzazione con il codice live e ingannare le persone in futuro, ecc. Ecc.
Detto questo, ci sono situazioni specifiche in cui un passaggio in fase di compilazione tra due percorsi di codice è ragionevole. Mentre stai sviluppando il nuovo codice e subito dopo, è possibile che sia necessario disporre di entrambi, in modo da poter passare facilmente da una all'altra. Se è probabile che tu debba tornare indietro o aggiungere un'opzione di configurazione esterna, un if se basato su una costante fornisce a tali un percorso di aggiornamento ragionevole. Quindi, come molte cose - se risolve un problema particolare, fallo. Altrimenti, evitalo.
La ragione per cui presumo che la gente faccia troppo è: dall'avere dubbi (spesso correttamente) che le persone effettivamente leggono la cronologia del controllo sorgente se hanno un problema; dall'avere paura il nuovo codice non funzionerà e vorrebbe una facile opzione di reversione. Un compromesso per provare ad adempiere ad entrambi potrebbe essere quello di inserire un commento "Modificato per calcolare ... on (Data) .Se qualsiasi problema, vedere la vecchia versione nel controllo del codice sorgente" o simile.
No, non è utile. Quel blocco else non ha alcuno scopo. Se non si è sicuri di quale implementazione utilizzare, commentarla, creare classi separate o salvarle 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 sarebbe male 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 utilizzare il seguente costrutto di commento:
//*
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 passare tra le alternative semplicemente aggiungendo o rimuovendo un singolo / nel codice.
Questo può sembrare un po 'strano all'inizio, ma una volta che ti ci sei abituato lo riconoscerai facilmente come una specie di modello.
Puoi persino incatenarlo e quindi scambiare più blocchi contemporaneamente con un singolo 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 rare occasioni in cui il vecchio codice e il fatto che sia stato sostituito, in realtà dovrebbero rimanere nel codice sorgente in modo che i futuri programmatori siano avvisati di qualcosa che è contro-intuitivo. Nel qual caso, c'è bisogno anche di una sorta di commento che spieghi perché è ancora lì e cosa è successo.
Come sempre, scrivere programmi di facile manutenzione significa rendere le cose più chiare, non solo seguire regole rigide e veloci. Se lasciare il codice morto in è più facile capire cosa sta succedendo, quindi lasciarlo. In caso contrario, quindi estrailo.
Sarà ignorato dal compilatore. Tuttavia sono d'accordo con te e vorrei solo rimuovere la dichiarazione else. Supponendo che stai utilizzando il controllo della 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 distrae quando si mantiene un pezzo di codice. Per qualsiasi attività, hai sempre più di un modo per realizzarlo, quindi devi sceglierne uno. Fai la tua ricerca, valuta gli algoritmi e scegline uno. Dopo questo, il codice non deve contenere alcun metodo alternativo 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 contiene la documentazione del progetto. Se lo desideri, puoi inserire un commento a una riga che fa riferimento a questo documento e spiega perché potresti voler leggerlo.
Non riesco a pensare immediatamente a una situazione in cui trovassi utile scrivere codice morto. Se ci sono algoritmi alternativi, allora:
In entrambi i casi, si finisce con nessun codice morto.
Se non elimini o commenta il tuo codice morto, dovrai mantenerlo per evitare errori del compilatore. È tempo perso. Eliminalo solo 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 opportunità di errori. Non appena inserisci un carattere nel codice, c'è un rischio. Quindi non aggiungere più del necessario.
L'unica volta in cui dovevo scrivere qualcosa di simile era come aggirare un bug del compilatore, è stato persino raccomandato dal fornitore del compilatore di usare questo lavoro.
Metti alla prova il codice morto che scrivi? Fai qualcosa per confermare che probabilmente è buono? Altrimenti, sbarazzati di esso.
Per future modifiche al codice, hai intenzione di verificare che il codice morto funzioni ancora? Altrimenti, sbarazzati di esso.
Non vuoi codice cattivo nei tuoi programmi, anche se non è usato. Averlo 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 dal momento che 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 ++, #ifdef edout code), ma questo dovrebbe essere accompagnato da commenti sul motivo per cui è ancora lì e a quale scopo serve.
Si noti che in Java, il seguente non verrà nemmeno compilato, a causa del codice irraggiungibile:
int someFunc() {
return 10;
int x = 12;
return x;
}
Idealmente, se c'è qualcosa di sbagliato nel tuo codice, lo vuoi trovare il prima possibile, piuttosto che lasciarlo andare in produzione e trovarlo dai tuoi utenti.
Se il tuo compilatore trova una classe di errori, lascia che sia il compilatore a trovarla. IMHO, ciò che qualcuno sta facendo scrivendo il codice morto nel modo in cui descrivi, sta tentando di aggirare l'errore del compilatore, consentendo qualsiasi problema che potrebbe causare a runtime in fase di esecuzione.
Potresti affermare che non è possibile raggiungere il codice morto, quindi non è possibile causare problemi, ma qualcosa potrebbe andare storto nei commenti, nei rinforzi e nei rientri che potrebbero farlo accadere.
Il motivo per cui le persone commentano una vecchia logica è perché hanno paura di apportare grosse modifiche al codice. E infatti, realizzando 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 qualche logica, non temere di perdere il codice presente in qualche modo funzionante. Rimuovilo e lascia che SVN / Git / TFS si occupino delle versioni per te.
Se non è il caso e hai appena prodotto due diversi pezzi di logica per fare qualcosa perché non ti importa di YAGNI o di DRY, quindi assicurati di metterlo in un posto dove le persone possono usarlo. Forse lanciare 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 qualche codice abbia ragione di esistere, assicurati di renderlo possibile utilizzarlo.
Un altro aspetto è che la maggior parte dei programmatori professionisti concorda sul fatto che la dimensione del codice è il nemico. Dai uno sguardo a questi post del blog: Il meglio il codice non è affatto un codice di Jeff Atwood, Il peggior nemico del codice di Steve Yegge, puoi trovare molto di più.
Le persone stanno facendo un sacco di cose per mantenere il loro codice conciso e impedire che codebase 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?
Solo il posto in cui ho visto che questo è utile è nei casi in cui si desidera disabilitare rapidamente qualcosa e test / backfill (il programma dice i passaggi A, B, C - richiedono molto tempo. Durante il backfill, si può scegliere di disabilitare B e C per accelerare il tempo se sai che non sono necessari).
Ma la verità è che in tutti i casi questo è molto hacky. E se vedi un utilizzo a lungo termine per il tuo codice di recupero, dovresti scrivere il tuo codice in modo tale che usi la configurazione per scegliere una scelta invece di usare tali hack.
La mia rapida regola del pollice è quella di non controllare mai questo tipo di codice. Se hai bisogno di un controllo di check-in / versione, significa che sarai in grado di tornare presto a questo, e che è sempre una brutta cosa alla luce del cambiamento dei requisiti.
In realtà, c'è un modo in cui è utile avere un codice "morto": quando vuoi che il tuo programma generi un'eccezione enorme perché ha raggiunto qualcosa che non dovrebbe mai accadere. Questo potrebbe essere un errore del compilatore, o se qualcuno up the line ha cambiato la logica nel test che stai usando, e lo ha rovinato. Ad ogni modo, il tuo "altro" invia fuochi d'artificio. In questo caso, vorresti ifdef 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" ...
Leggi altre domande sui tag java