- Introduction
- Colorized Tooltips
- Live Static Code Analysis
- Refactoring Code
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Live Static Code Analysis
Since ancient times, Visual Basic has performed live static analysis as you type, which means that the background compiler detected code issues and reported errors and warnings, suggesting possible fixes. In Visual Basic 2015 (and C# 6 as well), the code analysis engine has been completely rewritten for the .NET Compiler Platform. This change brings many advantages, including (but not limited to) the following:
- Managed compilers provide a built-in set of code analyzers, which send information to the code editor for immediate highlighting of errors and code issues, suggesting the proper fixes. They can also highlight redundant code. These analyzers take advantage of the new compiler's APIs.
- Because analyzers are based on the compiler's APIs, developers can build their own analyzers that integrate into the Visual Basic code editor. This means that Visual Studio 2015 offers specific extensibility points, and you can create analysis rules for your own APIs. The next article in this series will discuss this capability.
- Based on the .NET Compiler Platform and on the compiler's APIs, the Visual Basic editor introduces code refactorings, whose integrated tooling enables you to reorganize your code in a much cleaner way. As with the code analyzers, you can build custom code refactorings that integrate into Visual Studio. We'll examine this feature in the final article in this series.
In summary, the live static-analysis engine, now based on the .NET Compiler Platform, provides significant productivity improvements and allows for integration with your own analysis rules, which was impossible in the past.
Now let's look at some examples of code containing intentional errors, so that you can learn how to take advantage of the new live analysis engine and the new integrated tools. Imagine that you have a simple Contact class and some code that creates an instance of this class to use some of its members. Listing 1 shows a Contact class definition, plus code that creates an instance of this class.
Listing 1—Sample code with intentional errors.
'This is an unnecessary directive
Imports System.Linq
Class Contact
Property FirstName As String
Property LastName As String
Property EmailAddress As String
Property PhoneNumber As String
Function FullName() As String
Return $"{LastName} {FirstName}, {EmailAddress} - {PhoneNumber}"
End Function
End Class
Module Module1
Sub Main()
'Error: Contac does not exist
Dim newContact As New Contac
newContact.FirstName = "Alessandro"
newContact.LastName = "Del Sole"
newContact.EmailAddress = "alessandro.delsole[@]visual-basic.it"
'Warning: Converting to string is not necessary
Dim result = CStr(newContact.FullName)
Console.WriteLine(result)
End Sub
End Module
The code in Listing 1 contains the following errors:
- It contains an Imports System.Linq directive, but the code never uses members from this namespace; thus it is redundant.
- It attempts to create an instance of the Contact class using a bad object name (Contac).
- It is making a cast of the newContact.FullName invocation to an object of type String, but FullName already returns a String, so the conversion is unnecessary.
Now you will see how to fix these errors with a new friend: the Light Bulb.
Fixing Code Issues with the Light Bulb and Quick Actions
When the code editor detects that a piece of code needs your attention, it displays a symbol called the Light Bulb, as shown in Figure 2.
)
Figure 2 The Light Bulb symbol.
The Light Bulb shows a description of the code issue with the hyperlink "Show potential fixes." If you click this hyperlink, the code editor presents a list of possible fixes for the current issue and shows a live preview of changes. Figure 3 demonstrates this feature. In this case, the code analyzer suggests removing the unnecessary Imports directive.
)
Figure 3 Live preview for possible fixes.
Some considerations at this point:
- In this particular case, only one possible fix can solve the issue, but the Light Bulb can show long lists of possible fixes. Every potential fix is referred to as a quick action.
- The list of available quick actions per issue strictly depends on the code analyzer that detects the code issue. As you will discover shortly, in some situations a code issue can be solved in multiple ways, and the code analyzer provides these additional options.
- The live preview highlights in red any code lines that will be removed; lines highlighted in gray will be modified, and new lines to be added are highlighted in green.
To apply the suggested fix, simply click the desired quick action. If you are unsure whether to apply a fix, click the "Preview changes" hyperlink to open the Preview Changes dialog, where you can see a full view of the potential changes to your code. Figure 4 shows the Preview Changes dialog for this example. Notice that you can see the code without the unnecessary Imports directive.
)
Figure 4 Previewing code changes.
When you are convinced that you want to make the changes, simply click Apply to make the edits to your code; click Cancel if you don't want to make the suggested changes. Notice that the Preview Changes dialog shows the list of code files in which a change will be applied; you will be able to browse and preview every code file.
Going back to the live preview in the Light Bulb, you will be able to apply changes to the current document (the default option), to the current project, or to the entire solution (refer to Figure 3).
The next step in correcting our sample code in Listing 1 is fixing the bad identifier for the Contact class. Hover over this line:
Dim newContact As New Contac
The Light Bulb will appear, showing a number of quick actions, as shown in Figure 5. In this case, the Light Bulb provides several possible quick actions based on the context. The proper quick action to select is Change 'Contac' to 'Contact' (highlighted in yellow in Figure 5). Again, you will see a live preview of changes; simply click the appropriate quick action to apply those changes.
)
Figure 5 Selecting the proper fix among a list of quick actions.
The last fix is removing the redundant cast in the following line:
Dim result = CStr(newContact.FullName)
If you enable the Light Bulb, you will see one quick action offering to remove the unnecessary invocation to the CStr function, because the FullName method already returns String. See Figure 6 for details.
)
Figure 6 Removing an unnecessary conversion.
With just a few steps, you were able to fix all the code issues in your project as you typed, writing cleaner code and never losing focus on the code.
I mentioned previously that the Light Bulb can provide quick actions based on a specific context. This is a very important consideration that deserves an amazing example. For instance, suppose you want to implement the IDisposable interface on the Contact class. Add the following Implements statement in the class definition, without pressing Enter:
Class Contact
Implements IDisposable
A red error squiggle will highlight the IDisposable literal, because the class does not implement the interface yet. Because the code analysis engine knows what the IDisposable interface is intended to do, enabling the Light Bulb will display two quick actions. The first one simply implements the interface, as shown in Figure 7.
)
Figure 7 Implementing an interface.
The second quick action implements the IDisposable interface following the Dispose pattern, as shown in Figure 8.
)
Figure 8 Implementing the IDisposable interface with the Dispose pattern.
With this quick action, you can supply your code with the proper implementation of the IDisposable interface—without writing a single line of code!—by taking advantage of a context-based code analysis.
Now that you know how to leverage the Light Bulb and quick actions to fix errors and code issues, it is time to learn how to take advantage of this new tooling to refactor your code.