As developers, we always want to increase efficiency and readability in our code.
But it’s hard to keep track of every variable and code block.
With this in mind, here’s a great new tool I recently stumbled upon that I’d love to share with you. Our toolbox has definitely benefited from this.
It’s called SonarLint (https://www.sonarlint.org/), and is available in a bunch of different coding languages, usage methods, and IDEs – from Visual Studio or Code, to Eclipse or Atom.
First off, what is SonarLint?
At its core, SonarLint is the extension version of the SonarSource team’s application that reads over your code and pick up on potential logical or performance errors that you might have missed.
From there though, you have options. You can choose if you want SonarLint as an always-on extension to your favourite IDEIDE stands for Integrated Developer Environment. This is a specialized piece of software that helps developers create more software or..., or if you’d rather have a service that you upload your code to.
If you want it as a service, the team at SonarSource have you covered. You can either host it on your own server for free as SonarQube, or for a monthly subscription have it hosted on the cloud When referencing computing, the term 'cloud' refers to the generalisation of interconnected computers and services running on the Internet,... as SonarCloud.
Sounds good so far
For this post, I’m going to be talking about the SonarLint extension, which is what I’ve been using. My reasoning was simple. I wanted to quickly try it out but didn’t want to worry about setting up a VMA VM stands for a virtual machine. Virtual machines are a type of computing where you can host an entire..., installing everything, getting dependencies and whatnot.
I opened up an existing project when I installed SonarLint, just to see what would happen and how effective it’d be. It immediately picked up on a bunch of things that I hadn’t even considered:
A bunch of errors, from redundant if-blocks within if-blocks, unused variables, efficiency fixes. Each one linking to a rule list that shows examples of incorrect code, an explanation of why the rules exists, and their corrected version. I was surprised and amazed.
Not only that, it showed a bunch of more efficient approaches to LINQ statements that I hadn’t considered:
Did it improve efficiency?
Slowly but surely I went through all of the 200+ errors that I had, and it really gave a lot of food for thought regarding how we write our code here at Aerion.
Each unique error helped spark a conversation internally on how we have done things, whether we should implement the rule, and ultimately gave us a new point of view to consider in producing the best code we can.
It means that moving forward, our code will be more efficient, faster, and leaner. Which means happy clients.
