This lint rule detects useless break
statements at the end of case clauses in switch
or select
statements in gno code.
In go, switch
and select
statements do not fall through to the next case by default, unlike in some other languages. This means that a break
statement at the end of a case clause is unnecessary and can be safely removed, if gno also follows this behavior.
Detecting and removing these useless break
statements can improve code readability and prevent confusion, especially for developers coming from languages where fall-through is the default behavior.
The implementation consists of a function DetectUselessBreak
that inspects the AST of a Go file to find useless break
statements. The core logic includes:
- Traversing the AST to find
switch
andselect
statements. - For each case clause in these statements, checking if the last statement is an unnecessary
break
.
- Rule ID: useless-break
- Severity: warning
- Category: style
- Auto-fixable: Yes
- Description: Detects useless break statements at the end of case clauses in switch or select statements.
The rule considers a break
statement useless if all of the following conditions are met:
- It is the last statement in a case clause of a
switch
orselect
statement. - It is a simple
break
without a label (breakStmt.Label == nil
).
The implementation uses ast.Inspect
to traverse the AST and looks specifically for *ast.SwitchStmt
and *ast.SelectStmt
nodes. For each of these nodes, it iterates through the case clauses (*ast.CaseClause
for switch and *ast.CommClause
for select) and checks the last statement in each clause.
switch x {
case 1:
println("One")
break // Useless break
case 2:
println("Two")
break // Useless break
default:
println("Other")
break // Useless break
}
switch x {
case 1:
println("One")
case 2:
println("Two")
default:
println("Other")
}
- Positive: Improved code readability and reduced confusion.
- Negative: Minimal. Removing these statements does not change the behavior of the code.
- Should we extend the rule to detect useless
break
statements infor
loops as well? - How should we handle cases where the
break
statement is preceded by a comment? Should we preserve the comment? - Should we provide a configuration option to ignore certain patterns or in specific contexts?
- How do we ensure that this rule doesn't interfere with more complex control flow scenarios where a
break
might be used for clarity, even if it's technically unnecessary?