Discussion:
Sonar 4.5, Rule S1312 - Rename the "logger" logger to comply with the format "LOG(?:GER)?"
Gena Makhomed
2014-10-07 12:17:52 UTC
Permalink
Hello, All!

Sonar 4.5 Rule S1312
Rename the "logger" logger to comply with the format "LOG(?:GER)?"

is invalid, because logger objects is not constants,
and its should not be named as LOG or LOGGER.

is it possible to fix this bug, and change pattern
from "LOG(?:GER)?" to "log(?:ger)?" out of the box?

this is the most critical bug of Sonar, because it forces
junior programmers to crumple java source to make it
compatible with rule S1312 bugs and false positives.

P.S.

see also:

https://jira.codehaus.org/browse/SONARJAVA-432
Rule "S00115" on constant naming convention incorrectly assumes that all
static final fields are constants

Logger objects is static final, but logger objects is not constants.
--
Best regards,
Gena
Jean-Baptiste Lièvremont
2014-10-07 12:24:47 UTC
Permalink
Hello,

I do not agree with your assertion that logger objects are not constants: a
private, final, static field of type e.g org.slf4j.Logger *is* a constant.
The calling class will use the same instance during its whole lifecycle
(and if calls to LOGGER.log, LOGGER.debug, LOGGER.error, etc. change the
internal state of the Logger, then IMHO it's none of the developer's
business).

So I don't see any issue with this particular rule (although I agree with
you on the limitations of rule S00115).
Cheers,
-- JB.L


*Jean-Baptiste LIEVREMONT | *
*SonarSource **Core Developer*
http://sonarsource.com
Post by Gena Makhomed
Hello, All!
Sonar 4.5 Rule S1312
Rename the "logger" logger to comply with the format "LOG(?:GER)?"
is invalid, because logger objects is not constants,
and its should not be named as LOG or LOGGER.
is it possible to fix this bug, and change pattern
from "LOG(?:GER)?" to "log(?:ger)?" out of the box?
this is the most critical bug of Sonar, because it forces
junior programmers to crumple java source to make it
compatible with rule S1312 bugs and false positives.
P.S.
https://jira.codehaus.org/browse/SONARJAVA-432
Rule "S00115" on constant naming convention incorrectly assumes that all
static final fields are constants
Logger objects is static final, but logger objects is not constants.
--
Best regards,
Gena
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
Gena Makhomed
2014-10-07 16:24:47 UTC
Permalink
Post by Jean-Baptiste Lièvremont
I do not agree with your assertion that logger objects are not
constants: a private, final, static field of type e.g org.slf4j.Logger
*is* a constant.
Not all private static final objects is constants. For example,

private static final Set<String> set = new HashSet<>();

set object is not constant, but this object is private static final.


By analogy, objects, which implements interface org.slf4j.Logger
has mutable internal state and these objects can't be considered
as constants.

For example, public final class Logger implements org.slf4j.Logger
from logback - as you can see from this class source.


Objects with mutable internal state is not and never be constants.

Why you think that objects with mutable internal state is constants?

The object 'set' from first example - also must be named as 'SET' ?
Post by Jean-Baptiste Lièvremont
The calling class will use the same instance during its
whole lifecycle (and if calls to LOGGER.log, LOGGER.debug, LOGGER.error,
etc. change the internal state of the Logger, then IMHO it's none of the
developer's business).
in Code Conventions for the Java Programming Language
explicitly described, what only constants should be named
as all uppercase with words separated by underscores.

Object with mutable internal state is not immutable object,
and such mutable objects can't be considered as constants.

Constant is immutable object. Mutable object is not constant.
Post by Jean-Baptiste Lièvremont
So I don't see any issue with this particular rule
This rule contradict Code Conventions for the Java Programming Language.

And - common sense about 'constant value' / 'constant object' concepts.
--
Best regards,
Gena
Jean-Baptiste Lièvremont
2014-10-08 07:23:44 UTC
Permalink
The instance of the object you use does not change. The fact that the
instance's internal state is mutable does not change at all the fact that
it's still the same instance. So for me, a private static final field is
indeed a constant, since you can only assign it once. The fact that it is
mutable is a whole other story, that static code analysis cannot detect in
the general case.

So once again IMHO, from a static analysis point of view, the rule is
correct as it is: a private static final field is a constant and should
follow the associated naming scheme.

Now, just to push the envelope on this: how would you define a rule that
detects that a mutable object (e.g java.util.HashSet<?>) is used as a
constant (final field)? How, with static analysis (or even dynamic
analysis, and eventually a bit of introspection/reflection), can you detect
that an object is immutable? Hint: this is a popular subject for doctorate
thesis.

Best regards,
-- JB.L


*Jean-Baptiste LIEVREMONT | *
*SonarSource **Core Developer*
http://sonarsource.com
Post by Jean-Baptiste Lièvremont
I do not agree with your assertion that logger objects are not
Post by Jean-Baptiste Lièvremont
constants: a private, final, static field of type e.g org.slf4j.Logger
*is* a constant.
Not all private static final objects is constants. For example,
private static final Set<String> set = new HashSet<>();
set object is not constant, but this object is private static final.
By analogy, objects, which implements interface org.slf4j.Logger
has mutable internal state and these objects can't be considered
as constants.
For example, public final class Logger implements org.slf4j.Logger
from logback - as you can see from this class source.
Objects with mutable internal state is not and never be constants.
Why you think that objects with mutable internal state is constants?
The object 'set' from first example - also must be named as 'SET' ?
The calling class will use the same instance during its
Post by Jean-Baptiste Lièvremont
whole lifecycle (and if calls to LOGGER.log, LOGGER.debug, LOGGER.error,
etc. change the internal state of the Logger, then IMHO it's none of the
developer's business).
in Code Conventions for the Java Programming Language
explicitly described, what only constants should be named
as all uppercase with words separated by underscores.
Object with mutable internal state is not immutable object,
and such mutable objects can't be considered as constants.
Constant is immutable object. Mutable object is not constant.
So I don't see any issue with this particular rule
This rule contradict Code Conventions for the Java Programming Language.
And - common sense about 'constant value' / 'constant object' concepts.
--
Best regards,
Gena
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
Gena Makhomed
2014-10-08 17:45:25 UTC
Permalink
Jean-Baptiste,

You can see more details is JLS:

JLS §4.12.4:

A variable of primitive type or type String, that is final
and initialized with a compile-time constant expression (§15.28),
is called a constant variable.

JLS §6.1:

Constant Names

The names of constants in interface types should be, and final
variables of class types may conventionally be, a sequence
of one or more words, acronyms, or abbreviations, all uppercase,
with components separated by underscore "_" characters. Constant
names should be descriptive and not unnecessarily abbreviated.

JLS §8.1.3:

Inner classes may not declare static members, unless they
are constant variables (§4.12.4), or a compile-time error occurs.

=================================================================

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class TestConstants {
public class InnerClass {
private static final Logger logger =
LoggerFactory.getLogger(InnerClass.class);
}
}

We got compile error, so logger object is not constant, -
it is mutable object and it must not be named as 'LOGGER'.

=================================================================

More details, JLS §8.3.2.1:

At run-time, static fields that are final and that are initialized
with constant expressions (§15.28) are initialized first (§12.4.2).
This also applies to such fields in interfaces (§9.3.1). These fields
are "constants" that will never be observed to have their default
initial values (§4.12.5), even by devious programs (§13.4.9).

=================================================================

"constant" - is well defined term in Java Language Specification.

Authors: James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley
...for me, a private static final field is indeed a constant
What exactly term "constants" means is defined in JLS by James Gosling.
So once again IMHO, from a static analysis point of view, the rule is
correct as it is: a private static final field is a constant and should
follow the associated naming scheme.
Please, please, read exact definitions from Java Language Specification
Now, just to push the envelope on this: how would you define a rule that
detects that a mutable object (e.g java.util.HashSet<?>) is used as a
constant (final field)? How, with static analysis (or even dynamic
analysis, and eventually a bit of introspection/reflection), can you
detect that an object is immutable? Hint: this is a popular subject for
doctorate thesis.
We are talking now only about Java Programming Language
and about Code Conventions for the Java Programming Language.

In Java Code Conventions from Sun/Oracle you can read what only
constants should be named in ALL_CAPS_STYLE. *ONLY* constants.
See: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html

In Java Code Conventions from Google you can read, what only
constants should be named in ALL_CAPS_STYLE. *ONLY* constants.
See:
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.2.4-constant-names

Every constant is a static final field, but not all static final fields
are constants. Before choosing constant case, consider whether the field
really feels like a constant. For example, if any of that instance's
observable state can change, it is almost certainly not a constant.
Merely intending to never mutate the object is generally not enough.
Examples:

// Constants
static final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is
immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements =
ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

==========================================================================

Also you can read book Effective Java, 2nd ed. by Joshua Bloch:

The sole exception to the previous rule concerns “constant fields,”
whose names should consist of one or more uppercase words separated by
the underscore character, for example, VALUES or NEGATIVE_INFINITY. A
constant field is a static final field whose value is immutable. If a
static final field has a primitive type or an immutable reference type
(Item 15), then it is a constant field. For example, enum constants are
constant fields. If a static final field has a mutable reference type,
it can still be a constant field if the referenced object is immutable.

==========================================================================

Logger is mutable reference type and => logger in not the constant.

So, logger reference type must be named 'logger' and never 'LOGGER'.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Dear Sonar developer, please, please, fix this HUGE BUG S1312 in Sonar
and stop forcing developers to name mutable objects in ALL_CAPS_STYLE.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Rule S1312 should be

Rename the "LOGGER" logger to comply with the format "log(?:ger)?"

and must not be

Rename the "logger" logger to comply with the format "LOG(?:GER)?"
--
Best regards,
Gena
Jean-Baptiste Lièvremont
2014-10-09 07:18:32 UTC
Permalink
Gena,

I think we have a communication issue here.

First, thank you for all the pointers to the JLS and Effective Java; you
might probably not know that they are already valuable source of
inspiration for us at SonarSource, and I fully understand your point about
what to consider a constant or not - regarding the mutability of the
referenced object.

But my point remains valid: static analysis cannot detect, ahead of
execution, the mutability of an object. In your case, org.slf4j.Logger is
an interface, so you cannot determine what will be the implementation
provided at runtime. So you cannot determine the mutability of the
referenced object.

Then - and to answer your last point - if you're not happy with the
implementation of squid:S1312, you can either submit a pull request or
disable the rule in your quality profile, since it seems to generate much
noise on your side.

Best regards,
-- JB.L


*Jean-Baptiste LIEVREMONT | *
*SonarSource **Core Developer*
http://sonarsource.com
Post by Gena Makhomed
Jean-Baptiste,
A variable of primitive type or type String, that is final
and initialized with a compile-time constant expression (§15.28),
is called a constant variable.
Constant Names
The names of constants in interface types should be, and final
variables of class types may conventionally be, a sequence
of one or more words, acronyms, or abbreviations, all uppercase,
with components separated by underscore "_" characters. Constant
names should be descriptive and not unnecessarily abbreviated.
Inner classes may not declare static members, unless they
are constant variables (§4.12.4), or a compile-time error occurs.
=================================================================
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class TestConstants {
public class InnerClass {
private static final Logger logger = LoggerFactory.getLogger(
InnerClass.class);
}
}
We got compile error, so logger object is not constant, -
it is mutable object and it must not be named as 'LOGGER'.
=================================================================
At run-time, static fields that are final and that are initialized
with constant expressions (§15.28) are initialized first (§12.4.2).
This also applies to such fields in interfaces (§9.3.1). These fields
are "constants" that will never be observed to have their default
initial values (§4.12.5), even by devious programs (§13.4.9).
=================================================================
"constant" - is well defined term in Java Language Specification.
Authors: James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley
...for me, a private static final field is indeed a constant
What exactly term "constants" means is defined in JLS by James Gosling.
So once again IMHO, from a static analysis point of view, the rule is
correct as it is: a private static final field is a constant and should
follow the associated naming scheme.
Please, please, read exact definitions from Java Language Specification
Now, just to push the envelope on this: how would you define a rule that
detects that a mutable object (e.g java.util.HashSet<?>) is used as a
constant (final field)? How, with static analysis (or even dynamic
analysis, and eventually a bit of introspection/reflection), can you
detect that an object is immutable? Hint: this is a popular subject for
doctorate thesis.
We are talking now only about Java Programming Language
and about Code Conventions for the Java Programming Language.
In Java Code Conventions from Sun/Oracle you can read what only
constants should be named in ALL_CAPS_STYLE. *ONLY* constants.
See: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
In Java Code Conventions from Google you can read, what only
constants should be named in ALL_CAPS_STYLE. *ONLY* constants.
See: http://google-styleguide.googlecode.com/svn/trunk/
javaguide.html#s5.2.4-constant-names
Every constant is a static final field, but not all static final fields
are constants. Before choosing constant case, consider whether the field
really feels like a constant. For example, if any of that instance's
observable state can change, it is almost certainly not a constant. Merely
// Constants
static final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is
immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }
// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements =
ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};
==========================================================================
The sole exception to the previous rule concerns “constant fields,” whose
names should consist of one or more uppercase words separated by the
underscore character, for example, VALUES or NEGATIVE_INFINITY. A constant
field is a static final field whose value is immutable. If a static final
field has a primitive type or an immutable reference type (Item 15), then
it is a constant field. For example, enum constants are constant fields. If
a static final field has a mutable reference type, it can still be a
constant field if the referenced object is immutable.
==========================================================================
Logger is mutable reference type and => logger in not the constant.
So, logger reference type must be named 'logger' and never 'LOGGER'.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Dear Sonar developer, please, please, fix this HUGE BUG S1312 in Sonar
and stop forcing developers to name mutable objects in ALL_CAPS_STYLE.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Rule S1312 should be
Rename the "LOGGER" logger to comply with the format "log(?:ger)?"
and must not be
Rename the "logger" logger to comply with the format "LOG(?:GER)?"
--
Best regards,
Gena
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
Gena Makhomed
2014-10-09 11:26:49 UTC
Permalink
Post by Jean-Baptiste Lièvremont
First, thank you for all the pointers to the JLS and Effective Java;
you might probably not know that they are already valuable source
of inspiration for us at SonarSource, and I fully understand your point
about what to consider a constant or not - regarding the mutability of
the referenced object.
This not my point.

This is point of authors of JLS, James Gosling, Bill Joy and others.

This is point of authors of Java Code Conventions from Sun/Oracle.

This is point of authors of Java Code Conventions from Google.

This is point of author of Effective Java, 2nd ed - Joshua Bloch.

This is point of Code Conventions for the Java Programming Language.
Post by Jean-Baptiste Lièvremont
But my point remains valid: static analysis cannot detect, ahead of
execution, the mutability of an object.
Static analysis can detect "static fields that are final and that are
initialized with constant expressions" and Sonar can force code/style
conventions only to constant variables and enum constants,
as it already described in JLS and in Code Conventions.

If Sonar can't understand java source code (mutable object or not)
it should not (must not) make any suggestions about forcing code style.

Because these Sonar suggestions are false/invalid.

ALL_CAPS_STYLE by convention used ONLY for constants/immutable objects.

If object is mutable - developer should use camelCaseStyle for naming.

If developer can easy distinguish constants/immutable objects
from primitive variables/mutable objects - this is good thing.

If Sonar force developers to name mutable static final fields
in ALL_CAPS_STYLE - this is bad thing and convention violation.

Static analysis cannot detect many other things - this is normal.

But static analysis must not make assured suggestions
if it can't understand the source code and can't make
right suggestion about violations of already existing
code conventions in java world.

Sonar must not force developers to violate code conventions.
Because in this case Sonar is behave like wrecker / saboteur.
Post by Jean-Baptiste Lièvremont
In your case, org.slf4j.Logger is an interface,
so you cannot determine what will be the implementation
provided at runtime. So you cannot determine the mutability
of the referenced object.
I can, because I know which exactly implementation
will be used at runtime. Because I use logback for all services.

If Sonar can't determine mutable object or not
- it just should not make any wrong suggestions in rule S00115.

In case of rule S1312 - Sonar developers can determine,
what all/some implementations of interface org.slf4j.Logger
is mutable objects, and stop Sonar behave like wrecker / saboteur.
Post by Jean-Baptiste Lièvremont
Then - and to answer your last point - if you're not happy with the
implementation of squid:S1312, you can either submit a pull request
As I understand, such pull request will be rejected/ignored.
Post by Jean-Baptiste Lièvremont
or disable the rule in your quality profile,
since it seems to generate much noise on your side.
it seems to generate mush noise in any side of every Sonar user,
because logger is mutable object and current rule S1312 violate
all existing Code Conventions for the Java Programming Language.

Sonar role is to help developers to follow existing code conventions,
- not to violate it, as it now in 100% of Sonar suggestions of S1312.

You are disagree with me about Sonar role and main purpose?
--
Best regards,
Gena
Jean-Baptiste Lièvremont
2014-10-09 12:23:59 UTC
Permalink
Well, since you're the only one I see complaining about it, then either
other users of SonarQube are very shy (which I doubt), or they don't have
an issue with this single rule, amidst the thousands provided by the
ecosystem.

Helping developers follow convention and best practice is only part of
SonarQube's goal, the overall goal being the management of technical debt.

We feel that these rules (S00115 and S1312) are valuable along the
readability edge of technical debt management, for a wide range of existing
Open and Closed Source projects.

Finally, given that squid:S1312 is configurable (like most "controversial"
rules), if the default value of LOG(?:GER)? does not suit your standards,
then you can change it.

Cheers,


*Jean-Baptiste LIEVREMONT | *
*SonarSource **Core Developer*
http://sonarsource.com
Post by Jean-Baptiste Lièvremont
First, thank you for all the pointers to the JLS and Effective Java;
Post by Jean-Baptiste Lièvremont
you might probably not know that they are already valuable source
of inspiration for us at SonarSource, and I fully understand your point
about what to consider a constant or not - regarding the mutability of
the referenced object.
This not my point.
This is point of authors of JLS, James Gosling, Bill Joy and others.
This is point of authors of Java Code Conventions from Sun/Oracle.
This is point of authors of Java Code Conventions from Google.
This is point of author of Effective Java, 2nd ed - Joshua Bloch.
This is point of Code Conventions for the Java Programming Language.
But my point remains valid: static analysis cannot detect, ahead of
Post by Jean-Baptiste Lièvremont
execution, the mutability of an object.
Static analysis can detect "static fields that are final and that are
initialized with constant expressions" and Sonar can force code/style
conventions only to constant variables and enum constants,
as it already described in JLS and in Code Conventions.
If Sonar can't understand java source code (mutable object or not)
it should not (must not) make any suggestions about forcing code style.
Because these Sonar suggestions are false/invalid.
ALL_CAPS_STYLE by convention used ONLY for constants/immutable objects.
If object is mutable - developer should use camelCaseStyle for naming.
If developer can easy distinguish constants/immutable objects
from primitive variables/mutable objects - this is good thing.
If Sonar force developers to name mutable static final fields
in ALL_CAPS_STYLE - this is bad thing and convention violation.
Static analysis cannot detect many other things - this is normal.
But static analysis must not make assured suggestions
if it can't understand the source code and can't make
right suggestion about violations of already existing
code conventions in java world.
Sonar must not force developers to violate code conventions.
Because in this case Sonar is behave like wrecker / saboteur.
In your case, org.slf4j.Logger is an interface,
Post by Jean-Baptiste Lièvremont
so you cannot determine what will be the implementation
provided at runtime. So you cannot determine the mutability
of the referenced object.
I can, because I know which exactly implementation
will be used at runtime. Because I use logback for all services.
If Sonar can't determine mutable object or not
- it just should not make any wrong suggestions in rule S00115.
In case of rule S1312 - Sonar developers can determine,
what all/some implementations of interface org.slf4j.Logger
is mutable objects, and stop Sonar behave like wrecker / saboteur.
Then - and to answer your last point - if you're not happy with the
Post by Jean-Baptiste Lièvremont
implementation of squid:S1312, you can either submit a pull request
As I understand, such pull request will be rejected/ignored.
or disable the rule in your quality profile,
Post by Jean-Baptiste Lièvremont
since it seems to generate much noise on your side.
it seems to generate mush noise in any side of every Sonar user,
because logger is mutable object and current rule S1312 violate
all existing Code Conventions for the Java Programming Language.
Sonar role is to help developers to follow existing code conventions,
- not to violate it, as it now in 100% of Sonar suggestions of S1312.
You are disagree with me about Sonar role and main purpose?
--
Best regards,
Gena
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
Gena Makhomed
2014-10-10 12:40:16 UTC
Permalink
Post by Jean-Baptiste Lièvremont
Well, since you're the only one I see complaining about it,
then either other users of SonarQube are very shy (which I doubt),
Many other people also see these bugs/violations, for example,
Diorcet Yann at https://jira.codehaus.org/browse/SONARJAVA-432

Questions about "logger" vs "LOGGER" discussed at StackOverflow:
http://stackoverflow.com/questions/1417190 - many users doubt.
Post by Jean-Baptiste Lièvremont
or they don't have an issue with this single rule,
SonarQube have reputation as very smart and high quality software,
so many java developers usually completely trust Sonar suggestions,
because almost all SonarQube suggestions are almost always correct
and based on JLS, Code Conventions and CERT Java Coding Guidelines:

https://www.securecoding.cert.org/confluence/display/java/Java+Rules

https://www.securecoding.cert.org/confluence/display/jg/Java+Coding+Guidelines

I hope you also use these CERT Guides as valuable source of inspiration.
Post by Jean-Baptiste Lièvremont
amidst the thousands provided by the ecosystem.
Only a few SonarQube rules have issues, and most of these
ambiguous rules are disabled by default, because they
force users to violate Java Code Conventions, for example,
- rules squid:RightCurlyBraceDifferentLineAsNextBlockCheck
and squid:LeftCurlyBraceStartLineCheck

I am also almost happy user of SonarQube - thank you for your work!
Post by Jean-Baptiste Lièvremont
Helping developers follow convention and best practice is only part of
SonarQube's goal, the overall goal being the management of technical debt.
Ok, but technical debt is minimal if code is changeable, maintainable,
portable, reusable (as it described in SQALE method), you agree with me?

If java code violates common Java Code Conventions - such code is not
"changeable, maintainable, portable, reusable", because *violations*
make code hard ho change/maintain/port/reuse, you agree with me?

And, as it explicitly described in Google high quality document:
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.2.4-constant-names

static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

- loggers is mutable objects and must not be named as constants.

So, if rule S1312 force users to write code which violates conventions,
- SonarQube forces users to write low quality code, and SonarQube force
users to *INCREASE* technical debt. As I understand, Increasing
technical debt can't be goal of SonarQube, you agree with me?

If you agree with me in all cases, logical corollary is:

pattern in Rule S1312 should be "log(?:ger)?"
and must not be "LOG(?:GER)?", you agree with me?

If you not agree with me - please help me
to understand, what is my error and where it.
Post by Jean-Baptiste Lièvremont
We feel that these rules (S00115 and S1312) are valuable along the
readability edge of technical debt management, for a wide range of
existing Open and Closed Source projects.
Yes, but rule S1312 should help users to decrease technical debt,
and must not force users to write unmaintainable java code.

And rule S00115 can be little more smart and can do not force
users to violate code conventions (at least) in case of logger objects.

These two proposed changes are trivial, easy to implement,
and does not conflict with overall goal of SonarQube
- "the management of technical debt".

Contrariwise, these two proposed changes help SonarQube
to be the more useful instrument for managing technical debt.
Post by Jean-Baptiste Lièvremont
Finally, given that squid:S1312 is configurable (like most
"controversial" rules), if the default value of LOG(?:GER)?
does not suit your standards, then you can change it.
Current implementation of squid:S1312 rule conflicts with
the overall goal "being the management of technical debt".

Please, please fix this bug in SonarQube rule squid:S1312,
or please help me understand where is bug in my reasoning.

P.S.

Example of code, with Java Code Conventions violations
forced by SonarQube rule S1312 you can see for example,
here:

https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/transaction/ChainedTransactionManager.java

private final static Logger LOGGER =
LoggerFactory.getLogger(ChainedTransactionManager.class);

Example of code, conforming Java Code Conventions you can see,
for example here, in logback and SLF4J author's site:

http://www.slf4j.org/faq.html#declaration_pattern

final (static) Logger logger = LoggerFactory.getLogger(MyClass.class);

And even more details about Java Code Conventions for loggers, here:

http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.2.4-constant-names

5.2.4 Constant names

Every constant is a static final field, but not all static final fields
are constants. Before choosing constant case, consider whether the field
really feels like a constant. For example, if any of that instance's
observable state can change, it is almost certainly not a constant.
Merely intending to never mutate the object is generally not enough.

Examples:

static final Logger logger = Logger.getLogger(MyClass.getName());

=================================================================
--
Best regards,
Gena
Loading...