TL;DR overview
- The top five TypeScript issues detected by SonarQube for IDE include misuse of type assertions, unnecessary type annotations, dead code, cognitive complexity violations, and improper handling of promises.
- SonarLint catches these issues in real time within the IDE, providing immediate feedback before code is committed or pushed to a repository.
- TypeScript's type system offers strong safety guarantees, but developers frequently bypass them with type assertions or redundant annotations that reduce maintainability.
- Addressing these common issues early reduces technical debt and improves code readability across TypeScript projects.
Over the past 5 weeks, we've been counting down our top 5 issues that SonarQube for IDE sees in TypeScript projects. We dug into the SonarQube for IDE data to see which of its 300+ rules were invoked most often to flag a bug, code smell, vulnerability or security hotspot that could be caught before being committed. This is a round-up of all the issues and where you can look to learn more about them.
Naturally, these are all common issues and the consequences they can have on your application vary quite a bit. From confusing types to memory leaks and hard-to-spot bugs, these issues could impact both your end users and the cleanliness of your code. With SonarQube for IDE in your editor, these issues can be caught as you write them, saving time and keeping your code clean and bug-free.
The top 5
In reverse order, our top 5 common TypeScript issues are:
5. Optional property declarations
Starting with a type based issue, SonarQube for IDE often sees the combination of optional property syntax with union types that include `undefined`. While not necessarily a bug, this issue turns a type from something that communicates the intention of the developer to something that confuses. Get your optional property declarations right and your interfaces will describe your objects the way you meant them to.
4. Creating and dropping objects immediately
Creating an object but never using it is a code smell. It is either a mistake and you meant to assign the object to a variable and use it later, or it implies that you are creating the object to use a side-effect contained in the object's constructor. The former is easily fixed, the latter requires a refactor to remove the side effects from the constructor and turn them into a function that more clearly shows the intention.
3. Unused local variables and functions
Unused pieces of code can clutter your codebase, but they can also cause some interesting bugs and even memory leaks. Check out what can go wrong if you leave unused variables and functions lying around.
2. Non-empty statements should change control flow or have at least one side-effect
If a statement in your code doesn't cause a change somewhere, it's likely not doing anything at all, and code that doesn't do anything is of no use to our application. If the code was supposed to do something, then this is a bug, and one you'll want to catch early. Check out the ways that non-empty statements can crop up in our code.
1. Assignments within sub-expressions
Our top issue that SonarQube for IDE catches in all of our code is assignments within sub-expressions. This is either a readability concern, or more importantly, a bug where you assign inside a conditional statement instead of comparing. Spotting a missing = sign, or two, inside a conditional can be frustrating if you are hunting for the bug, but when your tooling points it out life is a lot easier!
Which have you seen?
So these are our top 5. I reckon I've written code that triggers each of these issues in my past. They come up all the time and avoiding them, or at least fixing them quickly, will make your code clean and your life better. There are plenty more potential TypeScript issues that SonarQube for IDE can help you spot in your application.
Keeping your code clean and bug-free as you write or refactor ensures your application will be more maintainable in development and work better in production. Now you've seen what these common issues can do, I hope you're prepared to keep them at bay and leverage the power of Code Quality to ensure your code remains an asset and not a liability.