Analysis of Code Defects and Their Repair Rates in Projects A and B

Background : The report examines code defects identified by SonarQube in two projects (Project A and Project B). It defines defects as potential or obvious errors such as null‑pointer exceptions, and introduces defect‑scanning tools (SonarQube, PMD, FindBugs).

Defect Types and Severity : Defects are classified into four categories – Code Smell (maintainability issues), Bug (functional problems), Vulnerability (security issues), and Security Hotspot (potentially risky code). Severity levels range from Info → Minor → Major → Critical → Blocker.

Experience Study : Based on two academic papers (CCF‑A and CCF‑B), the study analyzes why some defects are frequently fixed while others remain unresolved. High‑repair‑rate defects include Security Hotspots, easily identifiable Bugs (e.g., NPEs), and Code Smells. Low‑repair‑rate defects include Vulnerabilities and Security Hotspots that are hard to recognize, as well as certain Bugs that require specific knowledge.

Overall Project Defect Situation : SonarQube scans show that both projects contain many defects, dominated by Code Smells, with Bugs constituting a smaller proportion. Technical debt (Debt) and code duplication (Duplications) differ significantly between the two projects.

Bug Quantity : Project A and Project B each have a list of Bug‑type defects, the majority being null‑pointer exceptions. The high occurrence of NPEs contradicts expectations from the experience study, prompting deeper analysis.

Code Smell Quantity : Both projects exhibit similar distributions of Code Smell defects, indicating common maintainability issues that do not affect functionality directly.

Specific Analyses :

Null‑pointer defect residual reasons: many NPEs arise from unchecked null results; although the upstream service rarely returns null, the risk persists.

Code cloning defects: duplicated code across files propagates the same null‑pointer issue, multiplying risk.

Technical‑barrier defects: examples such as double‑brace initialization in Java create hidden references (e.g., Demo$1) that can cause memory leaks.

Test case misuse: a utility method public static double getDistance(double lng1, double lat1, double lng2, double lat2) rounds the result using integer arithmetic, leading to loss of precision. The accompanying test case asserts an integer value, failing to detect the bug.

Code snippet illustrating the faulty utility method:

/**
 * Calculate distance between two latitude/longitude points (meters).
 */
public static double getDistance(double lng1, double lat1, double lng2, double lat2) {
  double radLat1 = lat1 * RAD;
  double radLat2 = lat2 * RAD;
  double a = radLat1 - radLat2;
  double b = (lng1 - lng2) * RAD;
  double s = 2 * Math.asin(Math.sqrt(Math.pow(Math.sin(a / 2), 2) + Math.cos(radLat1)
      * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2));
  s = s * EARTH_RADIUS;
  s = Math.round(s * 10000) / 10000; // integer rounding loses decimal precision
  return s;
}

Corresponding test case that missed the defect:

// Call method: getDistance
double result = LatLonUtil.getDistance(1644.98, 10000.0, -1806.073394, 0.0);
assertEquals(1.0971114E7, result, 0.01); // expects an integer value

Reflections : Emphasizes the importance of early defect detection, careful design in complex business scenarios, rigorous test case creation, and awareness of technical debt. It calls for developers to treat test cases as defect‑finding tools rather than mere coverage metrics.