Hard coded string literals in loggers?

Hi, all.

I note that 5.1 has quite a few exceptions to the hard coded strings
checking. One surprising omission is in logging, which seems about as
likely to trip up as asserts or exceptions.

Similarly for magic characters - I often have some tucked into my log
statements, and do not mind them there.

Any chance of getting these added?

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

6 comments

Hello Scott,

SE> I note that 5.1 has quite a few exceptions to the hard coded strings
SE> checking. One surprising omission is in logging, which seems about
SE> as likely to trip up as asserts or exceptions.
SE>
SE> Similarly for magic characters - I often have some tucked into my
SE> log statements, and do not mind them there.
SE>
SE> Any chance of getting these added?

As there is considerably more variety in logging frameworks compared to other
items that can be ignored, we don't have a definite plan to support this
specifically for logging. The best way available now to exclude logging from
hard-coded string literals is to annotate logger fields or variables with
@NonNls.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Is there a reason that you can't implement it as a structural search pattern and allow the
user to specify the class and method names?

0

Hello Tim,

TH> Is there a reason that you can't implement it as a structural search
TH> pattern and allow the user to specify the class and method names?

There is no technical reason why this wouldn't be possible (structural search
is not really necessary - simple regexes would suffice). My main concern
is that I don't think that providing so many ways to achieve the same result
would be a good idea.

Maybe I'm simply too fond of all the cool tricks we did with @NonNls. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Dmitry Jemerov (JetBrains) wrote:

Maybe I'm simply too fond of all the cool tricks we did with @NonNls. :)


Please don't forget the poor people who have to use stock logging frameworks with JDK 1.4
occasionally - at least when they're not developing IDEA plugins ;)

Is that "external annotation" concept still something that's being considered:
http://www.jetbrains.net/jira/browse/IDEABKL-3524 ?

Sascha

0

Dmitry Jemerov (JetBrains) wrote:

Maybe I'm simply too fond of all the cool tricks we did with @NonNls. :)


Unfortunately, annotations are not an option for those of us stuck in J2SE 1.4 land.

0

In article <83ca25fd26138e8c7fb26487e88c0@news.intellij.net>,
Dmitry Jemerov (JetBrains) <yole@jetbrains.com> wrote:

Hello Tim,

TH> Is there a reason that you can't implement it as a structural search
TH> pattern and allow the user to specify the class and method names?

There is no technical reason why this wouldn't be possible (structural search
is not really necessary - simple regexes would suffice). My main concern
is that I don't think that providing so many ways to achieve the same result
would be a good idea.

Maybe I'm simply too fond of all the cool tricks we did with @NonNls. :)


Using annotations both prevents usage with 1.4 and requires me to litter
source code with annotations. Source code I own will get refactored, or
will get annotations, but source code I am working on for a client must
be carefully considered. They do not thank me if I make a change that
cannot be well justified, and this kind of cleanup is only justifiable
at most of my clients if I am making other changes at the same time.

The alternative is to turn off the inspection, which I have done. I
would rather not, though, because when I see a hard coded string not
going to an assert, a logger, or one of the other usual spots, it is
worth fighting that fight.

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0

Please sign in to leave a comment.