If peers agree that something isn’t really a bug, we can leave it coded that way.Īlthough Sonar metrics are aligned with OpenLMIS coding standards, you may disagree with the filters and metrics that Sonar is using. A good time to discuss this is the code review process. Sometimes SonarQube and SonarLint will show errors or issues that are not really a problem. We can use this to guide our discussions about what to prioritize as we work towards improved test coverage and quality. Bring up issues in the Fisheye review process.ģ) Periodically Triage: The teams map pull up Sonar periodically to look at our most common issues and to look at broader trends in test coverage. Also look at test coverage to consider whether the new code has enough tests. We want to clean up code as we touch it (fix as we go).Ģ) During Reviews: Open Sonar to look at errors and issues in the code during a review. There are three main use cases for Sonar that we are encouraging during the OpenLMIS v3 development:ġ) SonarLint plug-in in IntelliJ. It runs an immediate analysis as you change code, and by ‘binding’ your plug-in with the OpenLMIS SonarQube server, it uses the same set of rules and checks. The SonarLint IntelliJ plug-in allows you to see an easy report about code issues right inside IntelliJ. How Sonarlint works aka Sonarlint architecture?
It’s the only in-IDE solution you’ll ever need. Just install the plugin and continue to code while SonarLint assists you in the background.
Get maximum coverage for your programming language with no installation overhead or lengthy setup.
0 kommentar(er)
