Qual è la procedura migliore per contrassegnare le variabili che è necessario eliminare in seguito in Java?

Question

Mi sono grattato la testa per due settimane cercando di calcolare qualcosa basato su una variabile.

Si scopre che ho impostato la variabile in precedenza per risolvere temporaneamente un altro problema e non è mai tornato per correggerlo.

Normalmente, provo a contrassegnare il codice con // ToDo per ricordarmi di rimuovere la variabile temporanea.

In questo caso, non l'ho contrassegnato poiché stavo saltando in giro cercando di sistemare più di un paio di cose. (Non riuscivo a capire cosa stesse succedendo, quindi stavo provando ogni sorta di roba!)

Come contrassegni le variabili temporanee che desideri rimuovere in seguito?

1. Le istanziate come private nella parte superiore della classe?
2. Marco li linea con qualcosa come // Delete Me Later

Cosa c'è è la migliore pratica per la marcatura di variabili che è necessario eliminare più tardi?

(a breve di avere un cervello molto organizzata ovviamente ...)

Answer 1

invece di commentare ad ogni singola idea/raccomandazione, ho pensato di rispondere e poi si vota su questa risposta.

Innanzitutto, grazie per aver condiviso i tuoi processi e le tue idee. Lo apprezzo molto.

Penso che ci siano una serie di fattori in gioco che dovrebbero essere guidati dal desiderio di evitare di commettere errori stupidi o sofferenze da quelli che hai già fatto. Ne ho fatto uno (tra tanti.)

Supponiamo che il controllo della versione e le revisioni dei team vincano tutti; tuttavia al di là di controllo di versione (supponendo di aver commesso crappola al tuo buon codice):

• @deprecated è molto buona. Sembra fissarti. Abbiamo tutti bisogno di abbagliare. Speriamo di vedere la foresta tra gli alberi.

• Per me, le differenze sono onerose dal momento che spesso faccio cambiamenti radicali, ma è un grande suggerimento che funziona in molti casi.

Alcune cose importanti:

Dato che io sono di solito unico sviluppatore, mi baso su ToDos. Sono facili da usare. Ho un sistema di valutazione informale con tutti i giorni. Ad esempio, qualcosa che ha davvero bisogno di essere ripulito si presenta così:

//TODO * Might be a future crash here // where one star is something I really have to clean up before I ship. 
//TODO *** Can some lines be trimmed from this view adapter? 

Più stelle sono arbitrarie e forse addirittura opzionali. Continuo a pedalare attraverso di loro. @ BriGuy37: è stato un pensiero interessante. @ Sriram: anche questo è stato interessante: impostare i tag in determinate condizioni.

Nel mio caso, non ho dox il // TODO e mi ha bruciato.

grande regola forse per tutto questo è:

Unitize il vostro lavoro in un modo che non si fanno errori stupidi come questo. Sapere quali cambiamenti stai apportando e quando. Stai calmo.

Grazie ancora! È bello cogliere le best practice della community da incorporare nel tuo lavoro!

Answer 2

trovato dopo un po 'di googling, come ero curioso anche.

@Deprecated 
public void speak() { 
    System.out.println("Meow."); 
} 

Da Wikipedia, il Java annotations:

Java definisce un insieme di annotazioni che sono costruiti nella lingua . Annotazioni applicate al codice java: @ Override - Controlla che la funzione è un override. Causa un avviso di compilazione se la funzione non viene trovata in una delle classi parent. @Deprecated - Contrassegna la funzione come obsoleta. Causa un avviso di compilazione se viene utilizzata la funzione . @SuppressWarnings - Indica al compilatore di di eliminare gli avvisi di tempo di compilazione specificati nell'annotazione parametri Annotazioni applicate ad altre annotazioni: @Retention - Specifica in che modo viene memorizzata l'annotazione contrassegnata - Se solo nel codice, compilato nella classe o disponibile in fase di esecuzione attraverso la riflessione. @Documentato: contrassegna un'altra annotazione per l'inclusione nella documentazione . @Target: contrassegna un'altra annotazione per limitare il tipo di elementi java l'annotazione può essere applicata a @Inherited - Contrassegna un'altra annotazione da ereditare in sottoclassi di classe annotata (le annotazioni predefinite non vengono ereditate nelle sottoclassi).

Answer 3

usare l'annotazione @Deprecated

@Deprecated 
public void Test() { 
    // 
} 

Answer 4

La pratica migliore è quella di utilizzare il controllo di versione. Una volta corretto un bug, puoi git/hg/svn diff per controllare cosa hai fatto dall'ultimo commit e rimuovere eventuali modifiche temporanee. Se è necessario correggere altri bug, ma mantenere il "cambiamento temporaneo" su più commit, è possibile eseguire commit parziali (git add --patch o hg qrecord) in modo che le "modifiche temporanee" non vengano mai commesse e dimenticate.Per i provvisori molto grandi (non le migliori pratiche, ma potrebbe accadere), è possibile creare un ramo locale che si continua a reimpostare sul codice normale. Una volta che sei sicuro di rimuovere le "modifiche temporanee", puoi semplicemente ripulire eventuali modifiche non salvate e quindi verificare i problemi.

Answer 5

Filiali locali (git, modifiche di shelving in IntelliJ, due copie dell'origine verificate localmente), quindi quando si viene spostati da un'attività a un'altra, invece di eseguire semplicemente il lavoro completato parzialmente, si crea un secondo ramo e non commettere/spingere il primo fino a quando non è stato completato.

Coppia commette/spinge - in modo da non eseguire il commit fino a quando non si è parlato del codice con una seconda persona, che indicherà il blocco temporaneo del codice e chiederà informazioni su di esso. Spero che ti costringa a risolvere il dannato problema prima di commetterlo.

Non utilizzare TODO o altri commenti di questo tipo in quanto non verranno mai eseguiti.

Se è già pubblico e viene utilizzato esternamente, @Deprecarlo.

Answer 6

Prima di tutto, faccio precedere ciascun nome di variabile con "TODO_REMOVE_" o qualcosa di simile. In questo modo, se mi dimentico di rimuoverlo e qualcuno lo incontra più tardi, è chiaro che la variabile deve essere rimossa. Inoltre, se eseguo l'ultimo passaggio in basso, lo rimuoverò SEMPRE prima di effettuare il check-in.

Successivamente, aggiungo un commento TODO ad esso e lo annoto con Obsoleto. So che altri hanno detto che i TODO non sono mai stati attivati, ma quando eseguo un commit, il mio IDE (IntelliJ in questo caso) mi avvisa che ci sono X TODO in fase di commit. Se ricevi un messaggio simile quando effettui il check-in, questo dovrebbe far alzare una bandiera nella tua mente. Inoltre, se ti capita spesso di farlo spesso, crea un modello live, uno snippet o qualsiasi altra cosa che ti offre l'IDE, quindi devi solo digitare il tipo di classe e il nome della variabile.

@Deprecated 
Object TODO_REMOVE_variableName;//TODO Remove 

scorso, io cerco di ri-leggere, capire, migliorare, e confermare ogni riga di codice che scrivo prima di controllare un cambiamento nel set. Questo è fondamentale! So che all'inizio può sembrare scoraggiante, specialmente per grandi cambiamenti o quando si ha una scadenza incombente, ma è una goccia nel secchio vicino al tempo che ci ha messo a scrivere il codice, i problemi che rivela e il tempo futuro ne vale la pena. Davvero, vorrei che ogni sviluppatore lo facesse.

Answer 7

Se si utilizza Eclipse, vi suggerisco di

Avere un nuovo tag compito, dire 'Rimuovi', che potrebbe aiutare a identificare facilmente ciò che deve essere rimosso il codice temporaneo. Imposta la priorità su Alto.

Aprire la visualizzazione delle attività per controllare le attività RIMUOVERE e intervenire.

prega di passare attraverso di sotto di collegamento (un'interfaccia utente istantanea viene fornito troppo)

StackOverflow Q/A on Task tags

Answer 8

Se si utilizza SVN * e il cambiamento che si sta apportando è qualcosa che deve essere risolto prima che le modifiche vengano eseguite (ad esempio una modifica temporanea per il debug/test in locale) è possibile aggiungere un commento come // STOP-COMMIT e impostare un hook pre-commit che proibisce di commettere qualsiasi file contenente questo testo.

Questo funziona bene anche per contrassegnare le modifiche locali ai file di configurazione che non dovrebbero essere impegnati in SVN.

Se l'IDE supporta un elenco TODO che alla ricerca di commenti per una determinata stringa è possibile anche creare un formato TODO personalizzato cercando questa stringa.

* direi che si può fare qualcosa di simile con molti altri sistemi di controllo versione