2011-03-08 11 views
7

A scopo di test, spesso inizio a digitare del codice in un progetto già esistente. Quindi, il mio codice Voglio testare viene prima di tutti gli altri codici, come questo:Compilatore Java: basta lamentarsi del codice guasto

public static void main(String[] args) 
{ 
    char a = '%'; 
    System.out.println((int)a); 
    // To know where '%' is located in the ASCII table. 

    // But, of course, I don't want to start the whole project, so: 
    return; 

    // The real project starts here... 
} 

Ma il compilatore si lamenta del return -affermazione, per i seguenti motivi "codice morto". (Mentre in C++ il compilatore obbedisce il programmatore e semplicemente compila l'istruzione return)

Per evitare che il compilatore si lamenta, scrivo uno stupido if -affermazione:

if (0 != 1) return; 

lo odio. Perché il compilatore non può fare ciò che chiedo? Ci sono alcune bandiere di compilazione o annotazioni o qualsiasi altra cosa per risolvere il mio problema?

Grazie

+3

Mi raccomando di effettuare i test in classe esterna, i test di Junit potrebbero essere la soluzione. – reef

+1

@reef Penso che intendano "sperimentazione" piuttosto che test di unità – Rup

+0

Java ha una filosofia di progettazione diversa da C. C ti consente tutto ciò che non è esplicitamente proibito e non tenta di impedirti di commettere errori (presuppone che sia il tuo problema). Java cerca di impedirti di fare cose che non hanno senso e urlerà se sa che un codice non verrà eseguito. Piaccia o no, ma è così. –

risposta

10

Non ci sono flag da attivare per questo comportamento. Le regole che rendono il codice morto un errore in fase di compilazione sono part of the JLS (§14.21 Unreachable Statements) e non possono essere disattivate.

C'è una scappatoia esplicitamente nel circuito che permette di codice come questo:

if (true) return; 

someOtherCode(); // this code will never execute, but the compiler will still allow it 

Questo viene fatto in modo esplicito per consentire "commentando-out" o compilazione condizionale (a seconda alcuni static final boolean bandiera).

Nel caso foste curiosi: la scappatoia si basa sul fatto che un valore nota costante della condizione espressione di un if affermazione è non considerato al momento del check raggiungibilità di codice all'interno o dopo la dichiarazione if. Una situazione simile si verifica con while, dove i valori noti costante sono considerati, quindi questo codice non compilerà:

while (true) return; 

someOtherCode(); // this will be flagged as an unreachable statement 
+0

risposta perfetta. –

1

Non si dovrebbe avere un sacco di morti cod ein tuo progetto però due modi ottengo intorno a questo per la prototipazione.

Utilizzare/* */per commentare il codice.

// But, of course, I don't want to start the whole project, so: 
    /* 
    // The real project starts here... 


    */ 
} 

o creare un secondo metodo.

// But, of course, I don't want to start the whole project, so: 
    // realProject(); 
} 

public static void realProject() 
    // The real project starts here... 
} 
+1

Non suggerirei di usare '/ * * /' per commentare il codice "morto": porta al codice che è invisibile all'IDE: non si trova quando si fa "trova riferimenti", non è influenzato dal refactoring , non otterrai l'evidenziazione della sintassi e così via. Ho trovato il codice "morto" con "if (false) {}" è la soluzione più pulita. La soluzione migliore a lungo termine è ovviamente quella di rimuovere tutto il codice morto e lasciare che la cronologia viva solo nel sistema di controllo della versione ;-) –

+0

Intellij è abbastanza bravo nel refactoring del codice commentato (si lamenta anche che hai il codice nei tuoi commenti;) tuttavia, eliminarlo è solitamente la migliore politica. –

+0

IDEA lo fa? È pulito, ma suona anche un po 'fragile. Si lamenta anche degli esempi di codice in JavaDoc? –