Note: This is an extension of an earlier question I asked here: Do additional function/method definitions increase a program's memory footprint?
When I write a class, I usually end up writing several testing/debugging methods, used to make sure the class works as it should, or for printing data to help with debugging, or for unit testing, etc. Is there an easy/automatic way to make a release without these methods, or do I need to manually delete the extra code any time I want to compile a release version?
I ask this question both from a C++ and a Java perspective. I’m using Code::Blocks and Eclipse as IDEs, if that plays into the answer somehow.
From a Java perspective, there are a variety of strategies:
If it is snippets of code that produce log messages, use
log4jor one of the other logging frameworks.If it is a complete method that is unused in the production code, leave it there. At runtime, the JIT compiler will notice that it isn’t used and not bother to compile it. The code may still be there at runtime (as uncompiled bytecodes), but the impact on the memory footprint will be insignificant … given that the JVM needs a few megabytes of heap space just to get started.
If it is a class or collection of classes (e.g. JUnit test classes), put it/them in a parallel package with “test” somewhere in the package name, and filter it/them out when you create the JAR file.
If you are using Maven, put test classes in the “src/test/java” directory rather than “src/main/java”, and the maven command will automatically exclude them.
Some developers recommend using a sourcecode preprocessor with Java, but most would say that this is a bad idea; i.e. it introduces more problems than it solves. For a start, the mainstream Java IDEs and debuggers don’t understand proprocessor directives, so you are going to run into various tool-related issues. Besides, it is not the “Java way”.