Rider 2018.1.1 is released

A polished version of Rider 2018.1 is ready. Just click download to get the latest Rider 2018.1.1 bug-fix update working on your machine.

Among the many bug fixes, you will find some new features as well. Here are some highlights of this build we have prepared for you:
Continue reading

Posted in How-To's | Tagged , , , , , , | 2 Comments

ReSharper Ultimate 2018.1.1 bug fix update is here!

Hello from JetBrains! We have something interesting for you today. A few moments ago, we published the first bug fix update for our first release of the year – ReSharper Ultimate 2018.1.1.

Below, you can find a list of the notable changes:

Continue reading

Posted in How-To's | Tagged , , , , , , , , , , , | 33 Comments

Consistent code bases using Rider code analysis

In our series about Rider‘s code analysis, we’ve seen what it is and how it works, and looked at various examples of inspections that can spot warnings and errors in our codebase. Rider helps us learn common practices and language features, too, using over 2400 inspections coming from ReSharper and from IntelliJ-based IDEs.

Code style is a broad topic, which includes everything from project structure to tabs vs. spaces (bring in the pitchforks!), to documenting public APIs, to internationalization and localization of our libraries and applications. All of these are important in making our codebase easier to consume – both for ourselves and for new developers joining the team. In this post, we’ll look at how Rider’s code analysis can help us maintain a consistent code style throughout our project.

In this series: (table of contents will be updated as we progress)

Consistent project structure

One of the first things I personally do when opening a codebase is exploring where everything is and how things fit together. A clean and consistent project structure following some conventions helps us become familiar with the project and improves maintainability later on.

A good convention is that namespace declarations should match with the file location. In other words, when a class is located in a folder Extensions, we may want to have the namespace reflect this. Rider’s code analysis will show a warning when this is the case – and by now it should be clear there’s a quick fix to resolve this, too (Alt+Enter). The quick fix will update the namespace for the current file and update any using statements in other files when needed. Keep in mind this inspection can run solution- or project-wide, too.

Namespace does not match folder structure Continue reading

Posted in How-To's | Tagged , , , , , | 4 Comments

Learning best practices and language features using Rider code inspections

In the previous posts, we have seen how Rider‘s code analysis works and looked at how we can do things like spotting warnings and errors even before compiling and running our application. Rider helps us with such things by continuously validating our code using over 2400 inspections coming from ReSharper and from IntelliJ-based IDEs. In this post, we’ll look at how Rider’s code analysis can help us learn best practices and new language features.

In this series: (table of contents will be updated as we progress)

Learning best practices

Source code is the fabric we use to build solutions to business or technical problems. For any problem, there are many solutions available. And for every pattern, there are a number of anti-patterns. Rider’s code analysis helps in detecting possible improvements, provides quick fixes to apply them, and helps us learn best-practices in the process.

In the following code, range is an IEnumerable which we’re traversing twice: once in the foreach loop, once when calling Sum().

This is not considered good practice, as an enumerable can, in theory, be generating its elements multiple times, doing more work than needed. Imagine if that enumerable would run a database query in the background: we’d be running all those queries twice! Worse: an enumerable may only enumerate once, losing data and introducing unwanted behavior when we try to enumerate it a second time! Continue reading

Posted in How-To's | Tagged , , , , , | 4 Comments

Using Rider to spot errors before our application runs

In the previous two posts, we have seen how Rider‘s code analysis works: it continuously validates our code, analyzing it with over 2400 inspections coming from ReSharper and from IntelliJ-based IDEs. In this post, we’ll look at how we can make use of Rider’s code analysis to spot errors before compiling and running our application – saving time and getting feedback earlier in the development process.

In this series: (table of contents will be updated as we progress)

Compiler warnings and errors

We all know XKCD’s “My code’s compiling” comic. As developers, we like early feedback on what we are doing so we can keep doing what we were doing, without having to wait on things like compiling our code. Instead of having to compile, wait, then navigate to compiler errors, Rider will let us know upfront if something will break during compilation.

The most basic example would be invalid syntax: Rider will complain when something is wrong in our code – from a missing semicolon to a missing method and more:

Detecting syntax errors Continue reading

Posted in How-To's | Tagged , , , , , | 1 Comment

Solution-wide analysis in Rider

In a previous post, we looked at the basics of Rider‘s code analysis. We’ve seen that Rider continuously runs over 2400 inspections and validations on our code, informing us about potential issues and improvements while we are writing it. Code Analysis works with all languages supported by Rider and builds on inspections coming from ReSharper and from IntelliJ-based IDEs.

In this post, we’ll look at solution-wide analysis and how it can help us monitor code quality issues in our entire codebase at once – essentially providing us with an automated code review. We will also check out other ways to detect and fix problems in the scope of your project or solution.

In this series: (table of contents will be updated as we progress)

What is solution-wide analysis and where do I find it?

Solution-wide analysis in Rider does two things for us. First, it lets us constantly keep track of all errors/warnings in our solution, such as compiler errors or errors detected by code inspections. Second, it helps us find issues that can only be detected by analyzing the whole solution at once. Examples would be determining if a public member is used anywhere in the codebase, unassigned fields, …

We can enable/disable solution-wide analysis from Rider settings (Editor | Inspection Settings), from the Errors in Solution tool window (View | Tool Windows | Errors in Solution) or from Rider’s status bar:

Enable/disable solution-wide analysis from status bar Continue reading

Posted in How-To's | Tagged , , , , , | 4 Comments

Introduction to code analysis in Rider

One of the strengths of Rider is code analysis. Rider comes with over 2400 code inspections that analyze our code at design time, allowing us to instantly see any errors, problems or potential improvements – whether in the current file or in our entire solution.

In this blog series, we’ll look at what code analysis is, how it can do automated code review and how it helps us improve the quality of our code. Once we covered that, we’ll look into some of the inspection categories that are available and how they can help spot and resolve potential issues in our codebase.

In this series: (table of contents will be updated as we progress)

Let’s start at the beginning: what is code analysis?

What is code analysis?

How do we know if our code is correct? Unfortunately, there is no single answer to that question. We have to rely on various methods to validate code correctness:

  • Compile our code to check for compilation errors.
  • Run our application to check for issues at runtime.
  • Write and run unit tests to validate code logic.

There’s a downside to these three ways of validating code: they all require an explicit action. For example, to detect runtime errors we have to run our application, click through it and see if things are okay. We have to attach a profiler to figure out whether we implemented the Disposable pattern correctly. What if we could detect potential issues while writing code?

Code Analysis continuously looks at what we are doing and tries to determine what we want to achieve. Rider looks at individual statements and at our overall solution architecture. If it detects a potential issue, it will show a warning. It may show suggestions too, helping us make our code better. Let’s look at an example.

What does it look like in the editor?

We can access code analysis in a number of places, but let’s start with a place where it’s very obvious: in the editor. We’ll see our code get underlined with a “squiggle”, its color based on the severity of the code inspection result (hint, suggestion, warning, error).

Hovering over an inspection shows us what the issue is. In this case, we’re casting a Person to a Customer, which could result in a NullReferenceException at runtime.

Possible NullReferenceException - inspections in action Continue reading

Posted in How-To's | Tagged , , , , , | 2 Comments

Readonly structs, ref readonly and conditional ref expressions – C# 7.2 in Rider and ReSharper

Today, we continue our blog series about C# 7.2 language support in ReSharper and Rider.

In this series:

Last time we indicated that there is a remaining pitfall with in parameters. Let’s see why!

Readonly structs

There is one downside to using in parameters: for regular structs, they impose the compiler to generate copies whenever we call an instance member on it. But why do we need a copy? Didn’t we learn that in parameters will only allow us to read from that variable, and not to modify it? This is only partially true, because it only prohibits reassignments of the parameter. Instance methods of the struct are still allowed to mutate the reference by setting the this parameter – in other words, changing themselves – or reassigning fields or properties. So in order to guarantee our expectations on the call-site – that in parameters will not allow modifications – copies are being created:

The concept of readonly structs introduced with C# 7.2 can solve this issue. Adding the readonly modifier will ensure that all instance members as well as the value itself (this reference) will be completely immutable. We can’t change anything, neither from outside nor from inside the struct:

Continue reading

Posted in How-To's | Tagged , , , | 3 Comments

Leading digit separators, ref structs and in parameters – C# 7.2 in Rider and ReSharper

Time for another blog series! This time we will focus on the new C# 7.2 language features for which we’ve added support in ReSharper 2018.1 and Rider 2018.1. We will see how they help to improve our code quality and how they work under the hood.

In this series:

Let’s get started with something easy …

Leading digit separators in numeric literals

Beginning with C# 7.0, we can use underscores to separate large numeric literals into chunks of digits – thus called digit separators. Using digit separators can help to improve readability in our code base:

Prior to C# 7.2, digit separators were only permitted after the first significant digit of a hexadecimal or binary literal. This limitation has been removed so that we can now use the first group solely to specify the base (or radix) of our numeric literal. Other limitations from C# 7.0 remain the same, including that underscores cannot occur next to the decimal, next to the exponent character or next to the type specifier.

Speaking of numeric literals, we hope you didn’t miss our several new context actions for converting between different bases and adding/removing digit separators:

Converting numeric literals and adding digit separators

Continue reading

Posted in How-To's | Tagged , , , | 5 Comments

Better null checks, string formatting and path completion with JetBrains Annotations

In the previous blog post of our series around using JetBrains Annotations to improve Rider (and ReSharper’s) code analysis, code completion and navigation, we looked at some background: what are these annotations? And how do we add them to our source code? Now that we have them added to our code, we can look at some examples!

In this series:

We started our series with some ASP.NET MVC annotations (of which there are many more). Rider and ReSharper support a large number of annotations – let’s look at a few interesting examples.

Continue reading

Posted in How-To's | Tagged , , , , | 2 Comments