Java Compiler: Stop complaining about dead code

Question

For testing purposes, I often start typing some code in an already existing project. So, my code I want to test comes before all the other code, like this:

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...
}

But the compiler complains about the return-statement, because of the following "dead code". (While in C++ the compiler obeys the programmer and simply compiles the return statement)

To prevent the compiler complains, I write a stupid if-statement:

if (0 != 1) return;

I hate it. Why can't the compiler do what I ask? Are there some compilation flags or annotations or whatever to solve my problem?

Thanks

Farina

I'll recommend to make your tests in external classe, Junit tests could be the solution. – Usurer

@Usurer I think he means 'experimentation' rather than unit testing – Raama

Java has a different design philosophy than C. C allows you everything that's not explicitly forbidden and it doesn't try to stop you from making mistakes (it assumes that it's your problem). Java tries to prevent you from doing things that don't make sense and will shout if it knows that some code won't execute. Like it or not, but that's the way it is. – Walt

@Rup: I'd give the same advice for experimentation. I, for example, have a project called "scratch" with at least a single class ScratchMain with an empty main method in all of my workspaces ;-) – Walt

@Rup: yes I understood, this was kind of a recommendation for specific experimentation like the one exposed in his question. – Usurer

Answer 1

There are no flags to turn of this behaviour. The rules that make dead code a compile time error are part of the JLS (§14.21 Unreachable Statements) and can't be turned off.

There's an explicit loophole in the loop which allows code like this:

if (true) return;

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

This is done explicitly to allow "commenting-out" or conditional compilation (depending on some static final boolean flag).

In case you're curious: the loophole is based on the fact that a known-constant value of the condition expression of an if statement is not considered when checking reachability of code within or after the if statement. A similar situation occurs with while, where known-constant values are considered, so this code will not compile:

while (true) return;

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

Walt

Answer 2

You shouldn't have lots of dead cod ein your project however two ways I get around this for prototyping.

Use /* */ to comment out the code.

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


    */
}

or create a second method.

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

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

Scleroderma

I wouldn't suggest using /* */ to comment out "dead" code: it leads to code that's invisible to the IDE: it isn't found when doing "find references", it isn't influenced by refactoring, you won't get syntax highlighting and so on. I found wrapping "dead" code with if (false) { } is the cleaner solution. The best solution in the long run is of course to remove all dead code and let the history live in the version control system only ;-) – Walt

Intellij is pretty good at refactoring commented code (it also complains you have code in your comments ;) however, deleting it is usually the best policy. – Scleroderma

IDEA does that? That's neat, but it sounds somewhat fragile as well. Does it also complain about code samples in JavaDoc? – Walt

It gives you the option to update comments and strings when you rename a variable/method for example. Comments because you might be refering to a method/variable and strings because you might want to change the output of message to match the variable or you might be using reflections. Not sure about Javadoc as I don't use them often esp. with code in it. – Scleroderma