S1312 Naming convention for loggers

[Brian Sperlongano]

Hello,

Rule squid:S1312, Loggers should be "private static final" and should share a naming convention defines the allowable logger name as the regex "LOG(?:GER)".  In other words, only LOG or LOGGER are allowed.

An example of a compliant solution is:

public static final Logger LOG = LoggerFactory.getLogger(Foo.class);

Because of the naming convention restriction, this effectively limits the number of loggers per class to one, or the horribly worse case two, if you name one of them LOG and the other LOGGER!

On occasion there is legitimate reason to have more than one logger in a class for logging different things to different loggers.  Consider example:

public static final Logger LOG = LoggerFactory.getLogger(Foo.class);

public static final Logger LOG_STATISTICS = LoggerFactory.getLogger("STATISTICS");

public static final Logger LOG_COMPLIANCE = LoggerFactory.getLogger("COMPLIANCE");

I propose that the allowable logger names be expanded to allow any valid constant-style name (all uppercase with underscores) that begin with LOG_ or LOGGER_.

Thanks,

Brian

[Brian Sperlongano]

Hi,

Slight typo, my examples are intended to all be "private" not "public", but otherwise still stands.

Thanks!

Brian

[Michael Gumowski]

Hello Brian,

Did you encountered such False Negative in your code? Just wondering as usage of loggers by name is not a frequent use case. 

I tried to modify the parameter of the rule to also include LOG_* and LOGGER_*, and tested it on our code base of Java projects (120+ various Java projects, from 10k to 500k+ LOC). I didn't catch anything.

Before making any change to the rule, we would like to know if any other user from the community may be interested by changing its default behavior. For the time being, the best thing to do if you want to catch such cases is to modify the default REGEX, which would allow you to cover these cases.

Regards,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4f2ca4bb-48a3-42d9-a7ce-de9aa89658ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael GUMOWSKI | SonarSource

Software Developer @ Language Team
http://sonarsource.com

[Brian Sperlongano]

Hi Michael,

Thank you for pointing out the fact that the regex is editable!  I was able to change the regex to LOG(?:GER)?(?:[_A-Z]*) which looks like it should give the desired behavior that I was looking for.  So, my specific problem is solved, regardless of what the community decides.

However, consider that with the default settings, the rule as stated is "loggers must have a standard naming convention", but what you are actually enforcing is, in effect, "you may only have one logger per file".  Since logging is a good software practice that we want to encourage, it would seem that we should allow a breadth of names that allow you to define more than one logger.

Thanks,

Brian

[Michel Pawlak]

@Brian the rule is parameterizable. Why haven't you just modified the regular expression to fit your needs ?

@Michael: The main question about this rule should be "should logger instances systematically be declared final private static". My opinion is "no". Pros and cons are listed here: https://www.slf4j.org/faq.html#declared_static . 

If I had to change the rule I would rather split it in two ("final private satic" modifiers part and naming part) and would deactivate both rules in the default quality profile as there is no one-size-fits-all approach.

Michel

[Michel Pawlak]

@Brian: by the way why aren't you using SLF4J markers instead of using multiple loggers ? With markers you can have multiple appenders and achieve filtering using an evaluator. That's extremely powerful (you can for instance redirect logs to files based on markers, keep all logs related to a marker named "security", regardless of the log level or - my favourite - have markers for specific development teams). As a result you'll end up with cleaner code (only a single logger is defined by class). 

If you're using a compatible logging framework implementation, have a look at this great (but unfortunately underused) of slf4j.

Thinking about it, another approach would be to deploy kibana and have specific dashboards for each specific usage.

Michel