Here on the SubMain blog, I’ve already covered how to use CodeIt.Right to Create C# Coding Standards. Today Visual Basic gets the same treatment. In case you haven’t read the previous post (or any post in this blog at all), I’ll briefly explain what these posts are about.
CodeIt.Right is an automated code review tool. It checks the source code of your application against a set of rules (which can be the standard rules or custom ones), giving you instant feedback on its quality.
Similarly to the previous post, I’ll explain how you can create a Visual Basic coding standard by using CodeIt.Right. If your team doesn’t already know and use coding standards, then that’s a great opportunity for all of you to learn about all of the benefits you’re missing out on. I’ll begin by arguing that you need a coding standard. The SubMain blog has already covered that subject, but I’ll quickly revisit it.
Then I’ll go on to explain the usual problems teams face when trying to implement coding standards and code reviews in a totally manual way.
Lastly, I’ll explain how automation can solve those problems and how can you do so with the help of CodeIt.Right.
Visual Basic Coding Standard: What Is It?
As we did in the previous post, let’s begin by defining what we mean by “standard.” With that out of the way, the meaning of coding standard will logically follow. The word standard can have a variety of meanings, particularly in our industry. In a previous post about the need for a team standard, we make a clear distinction:
When I talk about the importance of a standard, I speak with the second flavor of the word in mind. I speak about the team looking at its code with a discerning attitude. Not just any code can make it in here—we have standards.
Think of standard as sort of a checklist, containing a list of the bare minimum quality criteria your work should meet. Checking every box in this list doesn’t automatically make your code good, in the same way that hitting F7 on Microsoft Word and proceeding to correct each one of the mistakes shown doesn’t automatically turn whatever it is you’re writing into the Great American Novel.
Yet it’s a step in the right direction. The first of many steps, but an important one, nonetheless.
Why Don’t People Use Coding Standards?
If you ask people why they don’t use a coding standard, they might offer you several explanations:
- They think a coding standard only deals with aesthetic concerns (e.g. spacing after parenthesis or placing curly brackets).
- Maybe they know a coding standard goes beyond cosmetic concerns, but they don’t think the benefits are worth the trouble.
- Finally, maybe they don’t even know that such a thing exists.
But what are the true benefits? What’s in it for you and your software shop in adopting a coding standard?
Coding Standards: What Are the Benefits?
The first benefit that I can think of is consistency. You wouldn’t want to correctly guess the author of a piece of code just by looking at it because that would mean there is a lack of consistency and too many personal peculiarities and preferences that are showing up when they should look uniform.
Now we turn to code review. Yes, there can be a lot of value in this practice. But there’s no denying that the code reviews can (and often do) turn into horror tales.
With a coding standard in effect, it’s possible to get rid of pretty much everything that can make a code review practice turn sour. When you have an authoritative guide people can refer to, politics doesn’t have a say in the matter.
The benefits of a coding standard rapidly start a virtuous cycle. A source code that benefits from consistency and less susceptibility to errors will cause the whole application to be easier to maintain and evolve.
Consistency can also facilitate the onboarding of new members and the swapping of members across teams, as well as the collaboration between teams. Code that is consistent and less error-prone will inevitably make an application that is easier to maintain and add new features to.
A smooth, non-stressful code review process will give you the usual benefits, but in less time and with less effort.
Coding Standards: Not Always a Bed of Roses
As the Rolling Stones have been telling us for decades, “You can’t always get what you want.” Sometimes you try as hard as you can and still fail. There are several problems one can face when trying to manually implement a coding standard.
The most obvious one is resistance, from both co-workers and management. People also often disagree on which set of rules to follow, but once you get over that, bigger dragons might still appear. How do you ensure that people are following the standard? How do you guarantee that such rules don’t become too heavy-handed and make people’s lives miserable and turn the work environment toxic?
Fortunately, there is a solution to these and other problems. And it’s none other than our very old friend “automation.”
If you can automate something, then you probably should do it. That’s a rule of thumb I use to decide whether to automate or not automate some process. The creation of a code review is definitely automatable, so by my rule of thumb, we should automate it.
By doing so, many of the problems you might encounter when trying to create a coding standard on your own just might disappear. Start small, with a default coding standard, and then adapt it as you need to.
Creating Visual Basic Coding Standards in Three Steps
Step 1—Start With a Basic Standard and Adapt It As Needed
Time is a very precious thing. You don’t want to waste yours in useless arguments about stuff that is mostly arbitrary. If there are two ways of doing the same thing with the exact same result, just pick the alternative you and your colleagues are most comfortable with and remain consistent.
CodeIt.Right comes with the Microsoft coding guidelines while also offering its own version of the guidelines: the SubMain .NET coding guidelines. Pick one of the two as your standard and then change it so it fits your team’s preferences. CodeIt.Right allows you to create custom profiles and also custom rules. That way, it gives you lots of power and flexibility so you can customize your standard to cater to your unique needs.
Step 2—Create a Design Guideline Document
Now your team has a Visual Basic coding standard. Congrats! Now you’re ready to evolve your approach. Are you done customizing the default standard you’ve picked so it better fits your particular needs and preferences? Awesome! Now it’s time to let CodeIt.Right generate a design guideline document for you.
As soon as you have this document, you can make it available in the corporate intranet, print it, and hand it over each time a new member joins the team, or even use it as a quick reference whenever a question about the standard comes up.
Step 3—Use CodeIt.Right to Automate Your Code Review Process
I have this rule of thumb to decide whether or not I should automate a process. And it’s dead simple: if you can automate something, then you should automate it. That frees you to focus on things that really require human intelligence, creativity, and empathy.
Code review isn’t an exception to this rule. Automate as much as you can of your review process. Whatever’s left after that is the non-automatable parts. That’s where the flesh-and-bone reviewers should focus.
Start Your Visual Basic Coding Standard. Today. I Mean It.
There are software organizations out there today that are working without a coding standard (and without version control, unit tests, or automated builds as well, for that matter). That really makes me sad.
Please don’t waste any more days missing out on the significant benefits that a coding standard can bring to the table. CodeIt.Right can save you from most of the suffering that generally accompanies the attempts of creating these standards.
Download it today and start harnessing its power to improve the quality of your team’s work.