Static Code Review and Refactoring

In your Simulation team, use today's lab time to focus only on the project's design rather than adding new features to correct these issues.

Before starting today's exercise make sure everyone has committed their latest changes on their branches just in case so no work is lost. At the end of the lab, you will create a Merge Request so the changes must approved by the team before being integrated.

Refactoring

SonarQube combines a number of static code analysis tools to report a variety of statistics and issues regarding your code. This analysis is performed by automatically looking for certain features in your code (such as that no instance variables are public). We have matched the general issues to the project's Design Checklist to clarify why these issues are relevant to your design. It should be noted that this analysis in no way guarantees your code is well designed, it only helps find obvious potential flaws and brings them to your attention. For example, it is an obvious design flaw to have public instance variables, but you can still have a bad design even if all of your instance variables are private.

You are not required to remove all issues found by this tool, but you should be prepared to justify why you left any issues in your code. This is best done in comments near the lines flagged as issues in the report.

Submission

At the end of class, use Gitlab's Merge Request to submit your group's refactored code to the team's repository. Make sure everyone's NetIDs are in the title of your Merge Request.