views:

85

answers:

4

Hi

I have just begun working on a C# application (using log4net). I'm supposed to add logs to code written by someone else. Hence, it's not possible for me to understand well the context each time (too much code, too less time :) ).

I have been following a convention which seems quite crude. I display log level, datetime, class name, method name with every log. I print the log on entering and exiting every method (most of them, i try to exclude method within big loops), in constructors, some events and every catch statement.

I think I'm overdoing it at places but some degree of uniformity is required. Any suggestions on the right (or better) approach?

+4  A: 

Logging the start and end of every method, and the constructors, is certainly overkill.

I'm afraid that if you don't understand the method you won't be able to log the appropriate issues.

At the very least log all exceptions, never catch an exception without doing something with it.

Joe R
You echo my thoughts :). I haven't left a single catch statement
kaustubh
+2  A: 

I suggest, you first of all find out what is the reason why the log is needed now. After all, the code you are working on was apperntly developed without much logging, so what is the reason they want you to add logging: do they have problems locating bugs (what kind of bugs?) do they want be able to see in retrospect when the program did something (what is this something?)?

Adesit
Or is it simply desired that the program is constantly printing something to the console, simply as a sign that it's still running.. ?
Adesit
Its a way to eliminate need for debug-trace buids later :)
kaustubh
+1  A: 

From my pov it is okay to log every function/constructor with input parameters and results in debug.
But keep the log messages as brief as possible as most data can be added/changed via the log4net configuration. Thus log only parameter1: value1 parameter2: value2 and result:x

weismat
A: 

Maybe you should also consider to log important conditional statements and their branches (entries), such as if/else if/else, and switch/case/default etc. This will help you provide more logic details inside the methods.

tonyjy
That would create too verbose log files, which certainly doesn't seem ideal for locating the actual issue. And as I said, it's not my code (I didn't write it), so I don't always know what branch is doing exactly what.
kaustubh