[crossfire] code cleanup commit.

[Mark Wedel]

Tchize wrote:
> Sorry, jumping in Thread a bit late.
> 
> I have quite a few experience with logging mecanism, here is my suggestion
> 
> Arrange log entries in a hierarchy (scopes) like is done in java logging 
> mecanisms:
> 
> example:
> common.object (for everything related to object)
> 
> Provide different levels of logging
> (idea: finest, fine, info, warning, error, critical), default visible 
> level would be info
> 
> Then you can say in config (or command line)
> default=warning
> common.object=finest
> server.monster=finest
> server=info
> random_maps=info
> socket=info
> 
> 
> Provide with the possibility to check if a specific level is enabled
> if (loglevel_enabled(scope,LOG_FINEST)){
>    /* do very complex operations here that can not be easily resumed in 
> a function call */
>    /* optionally at end issue a log call */
>     LOG(scope,LOG_FINEST,result_of_complex_logging_operations)
> }
> 
> Use also as information the line,file,function information, as 
> preprocessor provide them , but do not use them for filtering, use them 
> only when analysing a log to know where a problem occurs

  That all looks good.  But one question this - is it possible for a single log 
method to belong to several categories?

  I can see lots of things within the game where it is a question of 'is this a 
map related log message?  object?  monster?'  Since they all interact, it 
becomes tricky.

  I suppose this could perhaps get sorted out by clearly defining what 
categories something should be logged based on the operation in question.

  And I agree that log statements should generally always be enabled.  But often 
times, if you look at the log messages, the detail is just way too much to 
enable them all, even within a category, unless subcategories are defined or 
there are lots of category.

  A case I can think of here is the socket stuff.  I could see that if I'm 
writing a new socket command, I may want to have lots of logging info (at most 
detailed level) on what is going on.  But I don't want that high level of 
logging for the rest of the socket code (item, map, whatever else) as it then 
likely makes it too hard for me to find my own log information (oftentimes, you 
want to see those log messages as the program is running, not to look over the 
logs after the run).

  So I'm not sure how to best handle that.

  I do agree that if there are portable logging solutions already out there, 
that it makes sense to use them vs writing out own.