We're counting down the top 5 issues that SonarLint sees in all of our TypeScript, describing the issues and how to fix, or even better, avoid them.
This is probably not a surprise. Every time you're in your editor and you write a new variable tooling like SonarLint swings in to tell you that your variable is unused. You know it's unused because you haven't used it yet.
Issues like this are easy to fix, you keep writing the code you were intending to and use the variable that you defined. But there are plenty of reasons you might end up with unused variables that can cause problems.
As you write and refactor code, variables, and functions you thought you needed can become redundant. It's hard to keep track of every variable and function you write in your head so it's easy to leave them in a codebase and really useful when your tooling highlights it for you.
So what are the issues that unused variables or functions can cause?
The first relates to the readability of your code. If you delete old code but leave unused variables or functions lying around, the next time someone comes to read that code they will have to spend time working out whether those variables or functions are needed for something.
One interesting instance of unused variables I spotted in the wild looked like this:
Naming a variable that is unused with an underscore, or prefixing a variable name with an underscore, are conventions to show other developers that we had to name the variable, but we don't intend to use it. In this case, you don't need to name the variable though. You can actually ignore values in your destructuring assignment and just name the variables you want to assign to. So the above can be rewritten as:
Now the code won't make an unnecessary assignment and trigger this linting rule.
I believe in Clean Code, so not leaving extra bloat in a codebase and making things easier to read is important. The question is, can unused variables and functions actually cause bugs?
Of course they can!
Enter the following code in your editor:
You will see that
stop is unused. This highlights a human error, passing
start as both arguments to the
doSomething function when the second argument should have been
stop. Probably a result of hitting tab to autocomplete and the editor completing
start instead of
stop. An easy mistake to make, but one caught by this rule.
Copy the code and paste it into your editor and you will find that the function
unused is highlighted as an unused function. The fact that
unused refers to
originalThing within the function body means that the garbage collector is unable to reclaim the memory used to store
originalThing and so the memory usage of the application just grows over time. The investigation and fix for Meteor were a bit more complicated, but this example shows how even an unused function can cause issues in an application.
Poor readability, unnecessary code bloat, human error, and even memory leaks are all potential outcomes of an unused variable or function. That's why SonarLint enforces the rule that unused local variables and functions should be removed.
Removing or fixing unused variables and functions is a surefire way to keep your code clean and avoid potential problems. And it's a common enough problem to come in at number 3 in our countdown of the most common TypeScript issues.
So far in our Top 5 countdown: