Roslyn-Powered Code Views

by Mike-EEE

TL;DR: VOTE! ^

This post exists to build support around the idea of Roslyn-Powered Code Views. This is not intended to be a final solution, but a starting point for discussion, awareness, and a sign of demand. Show your support by voting for this idea here:

In this article, we explore the Visual Studio feature idea of what we are calling Code Views, and is an idea that can now be made possible with the advent of Roslyn.

StyleCop ^

The moment you realize that StyleCop is a File Format

The moment you realize…

The nature of the problem we are attempting to solve revolves around a product known as StyleCop.  A code file is considered compliant when it satisfies all of StyleCop’s many (many!) arbitrary rules revolving around its definition of code style.  To dig a little further, the problem isn’t StyleCop’s fault per se, but rather the problem that it attempts to solve in that of a standardized style for code within projects.

Eye of the Developer ^

StyleCop works wonderfully when you agree with all of its rules.  However, in practice you will find that is hardly the case.  The core problem with StyleCop’s approach is that it is attempting to place constrained limits on style, which is ultimately a very subjective quality.  Developers are incredibly creative individuals, and with that creativity comes strong opinions on a wide variety of matters, not the least of which is how to format the code that they create.

StyleCop’s view of style is just of one standard way of looking at code.  Furthermore — as you would expect for a subjective quality, as style is — many developers and organizations disagree with the (many) different rules of what StyleCop decrees and ultimately enforces.

The result of using StyleCop is that individual developers lose the freedom to design their code in a manner that they wish to design it.

Team Environments ^

This problem is not isolated to projects utilizing StyleCop.  Any developer who has worked in team environments know the pain of debating tabs vs. spaces or what line to place the opening brace.  These are all matter of style, and by agreeing to a “standard” style, ultimately one member’s definition of this style is what is enforced on all other members in the group — whether they like it or not.  Most developers simply go along for the sake of team unity.  Others will cause derision throughout a project’s lifetime by use of passive-aggressive commentary and thoughts behind the decided style.  Anyone who has been a part of such environment knows and understands the pain encountered here.

Enter Code Views ^

Roslyn-powered Code Views would solve this problem.  With Code Views, Roslyn first loads code in as an AST as it always does, but when it displays the code to the developer, it does so through a Code Formatting Profile that is configured to the developer’s preferences.  The developer then works in an AST that configured and presented precisely how they prefer it, maximizing their efficiency (and creativity).

Code Views: Opening a File

Code Views: Opening a File

When the developer saves the file, the current Code View is then composed into a Roslyn AST, all known (configured) StyleCop rules are applied to it, and then saved back into the source code file, which should be 100% StyleCop-compliant.  The results of which could be checked-in to source control to the delight of all its members.

Code Views: Saving a File

Code Views: Saving a File

Example Symbols and Format ^

To showcase some important concepts here.  Consider the following 100%-compliant StyleCop C# file:

//-----------------------------------------------------------------------
// <copyright file="Class1.cs" company="CompanyName">
//     Company copyright tag.
// </copyright>
//-----------------------------------------------------------------------
namespace ClassLibrary2
{
    using System;
 
    /// <summary>
    /// Placeholder text for Class1
    /// </summary>
    public class Class1
    {
        /// <summary>
        /// Placeholder documentation 
        /// </summary>
        private int field;
 
        /// <summary>
        /// Placeholder text for method
        /// </summary>
        /// <param name="parameter">This is a description for parameter</param>
        public void Method(int parameter)
        {
            var total = this.field = parameter;
            Console.WriteLine($"Hello World: {total}");
        }
    }
}

Now consider this same file as loaded and viewed after a theoretical Code Formatting Profile has been applied to it:

using System;
 
namespace ClassLibrary2
{
    public class Class1
    {
        int _field;
 
        public void Method( int parameter )
        {
            var total = _field = parameter;
            Console.WriteLine( $"Hello World: {total}" );
        }
    }
}

Hopefully you can see all the adjustments made by the Code Formatting Profile.  It is configured to:

  1. Put using statements at the top of the file, rather than within the namespace.
  2. Start field names with underscores (you can imagine other profiles as even enabling Hungarian notation).
  3. Not use the “this.” qualifier.
  4. Not qualify private members with the “private” keyword.
  5. Put inner spacing around parenthesis (to let code “breathe”).
  6. Use tabs instead of spaces (unfortunately the highlighter used for the code above does not preserve this).
  7. Hide documentation.  Some developers feel English and XML get in the way of the only language that actually matters: C#.  Of course, enabling and viewing documentation is (or should be if implemented properly) a keystroke away.

StyleCop as the Standard ^

By using Code Views, the developer saves their files to disk, and StyleCop rules are automatically applied to it to create a resulting code file.  The net result is that the file that is saved to disk is 100% StyleCop-compliant (or however compliant the team wants it to be).  This ensures that code is always in line with the style standard as currently offered by Microsoft. It also ensures a consistent, expected look and feel for any code that is stored on disk and (more importantly) in source control.

Creative Freedom ^

By using Code Views, code files are stored on disk (or in the cloud) in a 100% industry-standard format, while developers are able to view their code exactly how they want and prefer to view it.  Through the use and power of Roslyn, this is now possible. Please take a second to vote for this feature request by clicking on our Vote Now button below. Or, if you have feedback around this idea, feel free to sound off in our awesome Disqus comment section below.  Thank you as always for your support!

Show Your Support ^

If you like the idea of Roslyn-powered Code Views, please take the time and let Microsoft know by voting for this idea on UserVoice: