Learn static code analysis vocabulary: linter findings, SonarQube code smell density, security hotspots, technical debt ratio, code smell categories — the language of automated code quality tooling.
0 / 5 completed
1 / 5
The CI pipeline report says: 'The linter flagged 23 issues in the new code.' What does a linter do?
A linter (e.g., ESLint, pylint, Checkstyle) performs static analysis on source code — analysing it without running it — to identify style violations, suspicious code patterns, potential bugs, and deviations from defined coding standards. It enforces consistency across a team and catches common mistakes early in the development cycle.
2 / 5
SonarQube reports: '0.5% code smell density in the analysed code.' What is 'code smell density'?
Code smell density is a ratio metric: the number of code smells (design or style issues that indicate potential maintainability problems) divided by the total lines of code analysed. A lower density indicates cleaner, more maintainable code. SonarQube uses this to summarise the overall code smell burden of a project relative to its size.
3 / 5
The security scan reports: 'The security hotspot requires review.' What is a 'security hotspot' in SonarQube?
A security hotspot in SonarQube is a code pattern that is security-sensitive but not necessarily a confirmed vulnerability. Examples include: usage of cryptographic functions, SQL string construction, or file path operations. Unlike a vulnerability (which SonarQube considers a confirmed issue), a hotspot requires a human reviewer to assess whether the specific usage is actually risky in context.
4 / 5
The quality report shows: 'Technical debt ratio: 3.2%.' What does the technical debt ratio represent?
Technical debt ratio (in SonarQube's SQALE methodology) is the ratio of the estimated remediation cost (time to fix all issues) to the estimated development cost of the entire codebase. A ratio of 3.2% means fixing all the identified issues would cost approximately 3.2% of the time it took to write the code. SonarQube uses this to assign a maintainability rating (A through E).
5 / 5
The code reviewer comments: 'This is a classic God Class code smell.' What is a God Class?
A God Class (also called a God Object) is a code smell where a single class has grown to centralise too much of the application's knowledge and logic. It violates the Single Responsibility Principle. God Classes are difficult to test, maintain, and understand. Other common code smell categories include: long method (a method that is too long), feature envy (a method that uses data from another class more than its own), and data clumps (groups of data items that always appear together).