Source Code Analytics With Roslyn and JavaScript Data Visualization

verfasst von: Sudipta Mukherjee

Verlag: Apress

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

Learn how to build an interactive source code analytics system using Roslyn and JavaScript. This concise 150 page book will help you create and use practical code analysis tools utilizing the new features of Microsoft’s Roslyn compiler to understand the health of your code and identify parts of the code for refactoring.

Source code is one of the biggest assets of a software company. However if not maintained well, it can become a big liability. As source code becomes larger. more complex and accessed via the cloud, maintaining code quality becomes even more challenging. The author provides straightforward tools and advice on how to manage code quality in this new environment.
Roslyn exposes a set of APIs which allow developers to parse their C# and VB.NET code and drastically lower the barrier to entry for Meta programming in .NET. Roslyn has a dedicated set of APIs for creating custom refactoring for integrating with Visual Studio.
This title will show readers how to use Roslyn along with industry standard JavaScript visualization APIs like HighCharts, D3.js etc to create a scalable and highly responsive source code analytics system.
What You Will Learn
Understand the Roslyn Syntax APIUse Data Visualization techniques to assist code analysis process visuallyCode health monitoring matrices (from the standard of Code Query Language)Code mining techniques to identify design patterns used in source codeCode forensics techniques to identify probable author of a given source codeTechniques to identify duplicate/near duplicate code

Who This Book is For
.NET Software Developers and Architects

Inhaltsverzeichnis

Frontmatter

Chapter 1. Meet Roslyn Syntax API

Abstract

Until recently the biggest challenge for metaprogramming in .NET was that there was not a decent C# parser that could have been used to parse C# programs with confidence and keep up with the modifications made in the language specification. Some companies and individuals (including yours truly) have had to write their own parser to parse C# source code—because parsing is the first step to analyzing source code. Till Roslyn came into picture, compilers used to be like black boxes. Source code used to go at one end, and machine instructions/executibles came out the other end. However, in parsing code, compilers gained lot of knowledge, all of which used to get lost in the process. This knowledge could have served as the basis for writing analyzers.

Sudipta Mukherjee

Chapter 2. Code Quality Metrics

Abstract

Artists sometimes pause after they’ve been painting a while and step back. They relax and look at their painting. This gives them a clue whether they are doing what it takes to get to the picture of what they had been envisioning. We programmers can take a cue from our painter friends. While developing programs, developers can pause for a while to see whether we are getting where we wanted to go. However, till now all the resources we had worked on compiled assemblies. That means we couldn’t have checked the state as we go (from uncompilable source). Thanks to Microsoft, Roslyn changed that. With the Roslyn Syntax API, we can check our code as we build it—much like our artist friends.

Sudipta Mukherjee

Chapter 3. Design Quality Metrics

Abstract

When a house is built, the engineer first builds its plan and then a model. Once all the stakeholders are satisfied with the model, then they go about constructing the actual house. However, in the software industry, design is neglected. It may seem that the cost of a design alteration in software is not much, but it is enormous. It acts as a butterfly effect. Catching bad design choices early is every architect’s dream. But it doesn’t happen with software, for several reasons. First, once the design choices are described and laid out, several developers start to implement the design, much as workers keep working to make a house. However unlike working on a house, software developers check in their code after a code review. No design review happens beforehand—it’s unclear what the design review expectations would be. So, developers check in code that may work but that may be far outside the design choices made initially. Thus over time, as the codebase grows bigger and bigger, the design deviates from one part of the product to the other. If the overall code were compared to a huge castle, the architecture from one part of the castle to the next would be very different.

Sudipta Mukherjee

Chapter 4. Code Performance Metrics

Abstract

If you are programming for a while in an industrial setting, you know that most of the time, producing the right code that does what is expected is far more important than making sure it performs well. That said, in some systems performance considerations are of paramount importance. Getting your code to do the right thing and fast sometimes can be quite a challenge. Part of this challenge is to make sure that you know as a developer what will be the cost incurred in terms of running time for a coding construct. And because C#, like any other high-level language, lets you do the same thing in many ways, it becomes increasingly hard to keep abreast of the performance penalties due for coding constructs as newer versions of frameworks become available.

Sudipta Mukherjee

Chapter 5. Code Mining

Abstract

Code is art, and like other art forms like music and painting, good source code exhibits similar patterns. These are not only design patterns—they are regular code patterns that occur frequently. The information about code patterns can be helpful in a multitude of situations.

Sudipta Mukherjee

Chapter 6. Code Forensics

Abstract

This chapter is an extension to that. As I proposed in that chapter, imagine that two students submit code that looks plagiarized. Should credit be given for originality, and if so, who should get it? Who might be the original author and who might have been plagiarizing content?

Sudipta Mukherjee

Chapter 7. Code Visualization

Abstract

So far in the book you have seen how to use Roslyn and LINQ alongside C# to generate several meaningful metrics to determine code health. In this chapter you’ll see how to glue these metrics with some stunning state-of-the-art visualization to be rendered in the browser.

Sudipta Mukherjee

Backmatter

Titel: Source Code Analytics With Roslyn and JavaScript Data Visualization
verfasst von: Sudipta Mukherjee
Verlag: Apress
Electronic ISBN: 978-1-4842-1925-6
Print ISBN: 978-1-4842-1924-9
DOI: https://doi.org/10.1007/978-1-4842-1925-6