How Microsoft's next-generation compiler project can improve your code

I believe that every developer wants to write good code. No one wants to create a system that is riddled with errors, is not maintainable, needs to add functionality endlessly, or solves problems. I've been involved in a number of projects and I feel like I'm always in a state of chaos and no fun at all. It wastes a lot of time by making it difficult to understand the basic code because of inconsistent methods. I want to be in a project where the hierarchy is well defined, the unit tests are plentiful, and the build server runs continuously to ensure that everything is OK. Such projects typically develop a set of guidelines and standards that are strictly adhered to by developers.

I have seen a team that has developed such guidelines. Perhaps because some methods have been considered questionable, developers should avoid calling these methods in their code. Alternatively, they may want to make sure that the code follows the same pattern in some cases. For example, a developer in a project might agree with the following guidelines:

No one should use local DateTime values. All DateTime values should be in Coordinated Universal Time (UTC).

Avoid using Parse methods, such as int, that are found on value types. Parse), should instead be int. TryParse.

All entity classes that you create should support equivalence, that is, you should override Equals and GetHashCode and implement the = = and!= operators and the Iequatable<t> interface.

I'm sure you've seen similar rules in a standard document. Agreeing is a good thing, and if everyone follows the same approach, then it becomes easier to maintain the code. The trick is to quickly communicate this knowledge to all the developers on the team in a reusable, efficient way.

Code review is a way to discover potential problems. A person who is new to a given perspective can often find problems that the original author does not realize. Having the other party review your development work can be helpful, especially if the reviewer is unfamiliar with the work. However, it is still easy to ignore some of the problems in the development process. In addition, code review takes a long time--developers have to spend hours reviewing code and meeting with other developers to communicate issues that both sides find. I need this process to be quicker. I hope to learn as soon as possible after a mistake. Finding faults as soon as possible can save time and money in the long run.

There are several tools in Visual Studio, such as code analysis, that analyze your code and notify you of potential problems. Code analysis has a number of predefined rules that can reveal things like not destroying objects or unused method parameters. Unfortunately, code analysis does not run its rules until the compilation is complete, which is not fast enough! I want to be aware of this as soon as I have an error in the new code that I typed, based on my criteria. Finding faults as quickly as possible is a good thing. Saves time (and therefore saves money) and avoids the delivery of code that could cause countless problems in the future. To do this, I need to be able to code my rules so that these rules are executed as I type, which is what the Microsoft "Roslyn" CTP does.

What is Microsoft "Roslyn"?

One of the best tools that a. NET developer can use to analyze their code is the compiler. It understands how to parse code into various tags from the syntax and then change it to meaningful content based on where the tags are in your code. To do this, the compiler sends an assembly to disk in the form of its output. You can gather a lot of Hard-won knowledge in the compilation pipeline, and you are happy to be able to use that knowledge, but alas, this is not possible in the. NET environment because the C # and Visual Basic compilers do not provide APIs for you to access. The Roslyn has made a difference in this situation. Roslyn is a set of compiler APIs that reliably and completely accesses each phase of the compiler's experience. Figure 1 is a diagram of the different stages that Roslyn currently provides in the compiler process.

Figure 1:roslyn Compiler pipeline

Although Roslyn is still in CTP mode (The September 2012 edition is used in this article), it is worth taking the time to study the functionality provided in its assembly and to understand what can be done through Roslyn. It's best to focus on its scripting features first. With Roslyn, you can now write scripts for C # and Visual Basic code. That is, a script engine is provided in the Roslyn that allows you to enter code snippets into the engine. This functionality is handled through the ScriptEngine class. Here is an example that shows how this engine can return the current DateTime value:

          Class 

program
{
  static void Main (string[] args)
  {
    var engine = new ScriptEngine ();
    Engine. Importnamespace ("System");
    var session = engine. CreateSession ();
    Console.Out.WriteLine (session. Execute<string> (
      "DateTime.Now.ToString ();"));
  }

In this code, the engine creates and imports the System namespace, so Roslyn will be able to parse the meaning of the DateTime. After the session is created, it simply invokes Execute, and Roslyn will parse the given code. If it can parse the code correctly, it will run the code and return the result.

Making C # A scripting language is a powerful concept. While Roslyn is still in CTP mode, people use a small amount of their functionality to create stunning projects and frameworks, such as Scriptcs (Scriptcs.net). However, I think the real highlight of Roslyn is that you can create Visual Studio extensions to tell the problem when you write code. In the previous code snippet, I used the DateTime.Now. If the project I am working on implements the 1th I listed at the beginning of this article as a bulleted item, then I will violate that standard. Later I will explore how to use Roslyn to implement this rule. But before I do, I'll introduce the first phase of compilation: parsing code to get tags.

Syntax tree

When Roslyn analyzes a line of code, it returns an immutable syntax tree. This tree contains any information about a given code, including minutiae such as spaces and tabs. Even if this code is wrong, the code tree will try to provide you with as much information as possible.

This is good, but do you understand where the information is in the tree? Currently, there are few documents about Roslyn, which is understandable because it is still in the CTP. You can use the Roslyn forum to post questions (bit.ly/16qnf7w) or use #RoslynCTP tags on twitter tweets. When you install the file, there is also an example named Syntaxvisualizerextension, which is an extension of Visual Studio. When you type code in the IDE, the visualizer automatically updates with the current version of the tree.

This tool is essential to understand what you are looking for and how to navigate in the tree. In the use of the DateTime class. Now, I figured out that I needed to find memberaccessexpression (or, more precisely, a Memberaccessexpressionsyntax object), where the last IdentifierName value was equal to Now. Of course, this applies to the input "var now = DateTime.Now;" , and you might place "System." in front of the DateTime, or use the "using DT = System.DateTime;" In addition, there may be a property named now in other classes in the system. All of these situations must be handled correctly.