Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Update the plugin api #7777

Merged
merged 10 commits into from
Aug 15, 2023
Merged

Conversation

costin-zaharia-sonarsource
Copy link
Member

@costin-zaharia-sonarsource costin-zaharia-sonarsource commented Aug 10, 2023

In order to be able to update the RSPEC for clean code taxonomy.

Update of sonar-analyzer-commons

Release notes of sonar-analyzer-commons 2.6.0.1473 and 2.7.0.1482:

Copy link
Contributor

@antonioaversa antonioaversa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly remarks on the use of variables, questions on the dependency management across pom files and improvements on logging.

@@ -57,25 +57,39 @@
<artifactsToDownload>${project.groupId}:SonarAnalyzer.CSharp:nupkg,${project.groupId}:SonarAnalyzer.VisualBasic:nupkg</artifactsToDownload>
<!-- We are ignoring java doc warnings - this is because we are using JDK 11. Ideally we should not do that. -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Educational: is this comment still relevant? Are we still using JDK 11?
Should we rather remove <doclint>none</doclint>, since we are moving to JDK 17?
Or have a future task to do so?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this but it's not related to this PR. Could you please create a task to check and remove if possible?

pom.xml Show resolved Hide resolved
pom.xml Show resolved Hide resolved
sonar-csharp-plugin/pom.xml Show resolved Hide resolved
sonar-csharp-plugin/pom.xml Show resolved Hide resolved
@@ -36,6 +36,11 @@
<version>${findbugs.version}</version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Educational: both com.google.code.findbugs::jsr305 and org.slf4j::slf4j-api are defined as provided dependency, yet one relies on the version defined at org.sonarsource.dotnet::sonar-dotnet level, in the dependencyManagement, whereas the other relies on explicit versioning and properties inheritance.
Any reason for the difference in approach? Could we make the approach uniform, or explain the difference?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've missed this one. Thanks!

@@ -120,7 +121,9 @@ void analyze(SensorContext context, Coverage coverage) {
LOG.debug("The total number of file count statistics is '{}'.", fileCountStatistics.total);

if (fileCountStatistics.total != 0) {
LOG.info(fileCountStatistics.toString());
if (LOG.isInfoEnabled()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed offline, I would avoid adding those if (LOG.isXEnabled) before logging at Y level, because it may introduce issues (e.g. when X is different than Y) and also makes the code less readable.

Instead, I would adopt the approach defined here. The day the facade will support Log4j lazy logging API, we will either change the signature of the lazy method, to return the input Callable<?>, or we would just drop the lazy call, unwrapping its parameter.

@@ -44,7 +44,9 @@ public class DotCoverReportsAggregator implements CoverageParser {

@Override
public void accept(File file, Coverage coverage) {
LOG.debug("The current user dir is '{}'.", System.getProperty("user.dir"));
if (LOG.isDebugEnabled()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.

Applies to all occurrences of if (LOG.is in the changes below.

LOG.debug("Adding file type information (has MAIN '{}', has TEST '{}') for project '{}' (project key '{}', base dir '{}'). For debug info, see ProjectInfo.xml in '{}'.",
hasMainFiles, hasTestFiles, getValueOrEmpty(configuration, PROJECT_NAME_PROPERTY),
getValueOrEmpty(configuration, PROJECT_KEY_PROPERTY), getValueOrEmpty(configuration, PROJECT_BASE_DIR_PROPERTY), analyzerWorkDir.get());
if (LOG.isDebugEnabled()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe for this case specifically, it makes sense to keep the if (LOG.isXEnabled()), because the alternative is wrapping each of the 6 parameters into a lazy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it anyway to be consistent.

sonar-vbnet-plugin/pom.xml Show resolved Hide resolved
Copy link
Contributor

@antonioaversa antonioaversa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for all the explanations!
I left a minor comment about inlining a short ternary operator.
It is optional, and in case can come in a later PR.

Just a remark: we have introduced quite a few deprecation-related Code Smell, so SC Quality Gate is failing on Maintainability.
We will catch up soon on that, removing calls to set severity and rule type, in favor of quality, impact and CCT attribute.

public String toString() {
try {
Object result = callable.call();
return result == null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would write this ternary inline, since it's short and simple to understand.

@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell B 30 Code Smells

98.9% 98.9% Coverage
0.3% 0.3% Duplication

idea Catch issues before they fail your Quality Gate with our IDE extension sonarlint SonarLint

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants