include logging?

[BillLeighton]

I understand the value of using extensive logging during the development process, but would it be bad to leave logging code (even SEVERE logging) in the final project? I understand the general thought is not to leave JUnit tests in the code, particularly as the submitter did not write JUnit, but the logging stuff is Sun's , and seems fair game...

[Andrew Monkhouse]

Hi Bill
Personally I did not have any logging at all in my application.
However, if by default, logging was turned off, and the logging was done properly, then it should be OK - it shows that you are thinking about maintainability.
By properly, I mean that you do use the different log levels ( so you don't get an all or nothing approach to logging), and maybe (if possible) you have a modular approach to logging (so you can say only turn on logging for networking for instance).
The problem of course, is that if you get it wrong, then the examiner may look at what you have written and decide to take a mark off in the "general considerations" section.
Regards, Andrew

[Damian Ryan]

I did exactly what you suggest, Bill, and left all my logging code (Java 1.4 logging API) in my submitted code.
I used system properties to allow individual packages to have their logging switched on to an appropriate level, the default being no logging if no property was supplied with the command line (as would be the case when the assessor runs the code).
For example:

java -Dsuncertify.db.loglevel=INFO suncertify.client.Client 

would run a main class called suncertify.client.Client, with logging level set to "INFO" (all INFO and above logged) for any classes in the suncertify.db package.
And

java suncertify.client.Client 

would do the same, but because no logging properties has been set, all packages would have their log level set to "NONE".
This required the help of a very simple (a few lines) helper class to read system properties and set up log levels appropriately.
I found the logging very helpful during development and testing, especially when ensuring threadsafe concurrent access to the database, but I would echo what Andrew said about making sure you do it right if you are going to use it. But it's really not that difficult, so be brave!
BTW, I didn't lose any marks for my approach.

[Max Habibi]

I agree wholeheartedly: leave the logging in, but with a caveat. Don't log to a file. Why not? Mostly because it introduces the risk that something might go wrong at the IO level, thus causing your project undue burden. Log away, IMO, but only to the default err.
M

[Jim Yingst]

If you use java.util.logging, then logging level and handlers can be controlled entirely by the logging.properties file. By default this sets up a single console handler at level INFO. For your own debugging you can certainly add logging to a file at whatever level you want by changing your logging.properties file - this won't affect logging on the test examiners' machines, because they will have their own logging.properties. If they have chosen to set up logging to a file, that's their business, not our problem. By default though they will just see console logging at INFO level.