Why is this an issue?
The primary purpose of classes that implement indexed access operators is that of element access, like this is the case for arrays, lists, maps, or
sets. When a class implements indexed access operators, they should be used as operators instead of calling them as functions, because this is the
intention of the designer of the API.
What is the potential impact?
Readability and Understanding
This change makes it easier to understand what a function does, because the semantics of indexed access operators is evident to the reader, while
for a function call, the reader would need to know what the called function does.
How to fix it
Replace instance.get(index) with instance[index].
Replace instance.set(index, value) with instance[index] = value.
This also works with multi-index access operators.
Code examples
Noncompliant code example
interface Grid {
operator fun get(row: Int, column: Int): Int
operator fun set(row: Int, column: Int, value: Int)
}
fun indexedAccess(list: MutableList<Int>, map: MutableMap<String, Int>, grid: Grid) {
list.get(1) // Noncompliant
list.set(1, 42) // Noncompliant
map.get("b") // Noncompliant
map.set("b", 42) // Noncompliant
grid.get(1, 2) // Noncompliant
grid.set(1, 2, 42) // Noncompliant
}
Compliant solution
fun indexedAccess(list: MutableList<Int>, map: MutableMap<String, Int>, grid: Grid) {
list[1] // Compliant
list[1] = 42 // Compliant
map["b"] // Compliant
map["b"] = 42 // Compliant
grid[1, 2] // Compliant
grid[1, 2] = 42 // Compliant
list.getOrNull(2) // Compliant, because function is not an operator
list.getOrElse(3) {42} // Compliant, because function is not an operator
map.getValue("a") // Compliant, because function is not an operator
map.getOrElse("c") {42} // Compliant, because function is not an operator
}
Resources
Documentation
