Hi all!
Thank you to everyone who attended our webinar yesterday! You can find below the questions that were asked during the session:
Q: Would a Branch analysis be best completed on a Master Branch or a Release branch?
A: The branch analysis can be done on both the Master and Release branches. We recommend doing both here, however it depends on your specific branch strategy. Larger teams with more detailed branch strategies, especially those practicing DevOps, will benefit from analyzing their branches or pull requests. This way, new code is cleaned in the branch or pull request before merging into main, and main remains clean and production-ready at all times.
Q: Are these setups (i.e. new code definition, quality gate) the same in the SonarQube Community Edition, or is it specific to the Cloud version?
A: These setups are generally the same on SonarQube Community Edition and SonarCloud. New code definition options are slightly different between SonarQube and SonarCloud. Note that PR analysis is not available in this version.
Q: What tends to be the most widely used clean-as-you-code duration, e.g. 30 days, 90 days, 180 days?
A: Previous version and number of days are popular options. When the number of days is used, 30 days is the popular duration.
Q: Is there a Community Edition of SonarLint?
A: SonarLint is free to use. We do not have specific editions. Feel free to use it anytime 
Q: Will SonarQube create an estimate for fixing issues?
A: Yes, SonarQube contains information on time estimates for the effort to resolve each issue.
Q: What if we have critical issues, such as vulnerabilities, in the overall code that we care about?
A: To cover this use case, you can add quality gate conditions to the overall code. This will complement the Clean as You Code practice.
Q: We cannot achieve high coverage or duplication as recommended by Sonar Clean as You Code. So what should we do in this case?
A: You may customize the coverage and duplication thresholds in a Clean as You Code-compliant quality gate to suit your team’s needs.
Q: One challenge I find in the “clean as you code” approach is consistency. I sure like my code to be consistent when possible… so I have a difficult time accepting partial solutions in one library that I’m touching today knowing the same issues exist elsewhere. But once you start pulling the thread, you don’t know how long it’ll be! Any words of wisdom to share?
A: By practicing Clean as You Code, your overall code will become cleaner over time as you touch legacy code to make new changes. Eventually, those other issues in the overall code will align with your consistent coding style.
Q: How does Generative AI for Code Assist help with Clean as You Code, like GitHub Copilot, AWS Codewhisperer or Google Gemini? What is SonarSource Gen AI strategy?
A: Sonar embraces using GenAI-assisted coding. We have an article that talks about Clean Code in the Age of Generative AI. You can find out more here: AI Generated Code in Software Development & Coding Assistant
You can also check out the Gen AI webinar we did recently on Coding Assistants and Sonar: Webinars | Code Faster, Write Cleaner using AI Coding Assistants and Sonar
Q: if I mark an issue as “Known” or “False positive” will it pop up again in future MRs in the same file would be touched?
A: An accepted issue will not appear as open automatically in the future.
Q: In our development environment, we have a large team of over 100 developers collaborating on a codebase comprising more than 50 million lines. Our pull request scans consistently reveal significant technical debt, often exceeding 45 days’ worth of effort. Given the scale of this challenge, expecting individual developers to address all of this would be impractical. How can we properly address this?
A: The Clean as You Code methodology requires you to focus on new code in the Pull Request so your development teams do not become overburdened by all the issues in the overall code. Over time, the issues in the overall code will improve as you touch sections of it to create new code. 45 days of effort in a pull request seems unusual. Consider checking if the PR itself is not huge or if there are any issues with the configuration.
