Code Style Settings in ReSharper

ReSharper makes a clear delineation between the concept of a formatter (a component that changes the way code looks but does not change the syntax) and the code style settings, a piece of functionality that can, in fact, change syntax without changing the semantics. This blog post covers the updates to the code style settings that appear as part of ReSharper 10.

For example, no keyword has caused more C#-related holy wars than the ubiquitous var. Well, ubiquitous for some, since many people still prefer to hold a belief that var is a form of obfuscation. The choice of using or not using var is, of course, personal, and so it makes sense for ReSharper to provide settings for controlling how things like var, this. qualifiers, and other constructs are used in code.

ReSharper code style settings

These Code Style Settings exist in many languages: ReSharper supports them in C#, VB.NET, JavaScript/TypeScript and, of course, C++. Each of the settings generally consists of three distinct parts:

  • The setting description is fairly self-descriptive, though some settings are grouped and, in some cases, you can collectively change a setting for the entire group.
  • The preference determines how code is actually used. In some cases this is a yes/no switch (e.g., whether or not you want to use a private modifier explicitly), in other cases it’s a list (e.g., for var usage), and then there are more complicated settings such as the order of modifiers.
  • The notify with option, which is only available on some code style settings, lets you control how a setting violation is presented: as a hint, suggestion, error or warning or… avoid notifying the user altogether.

That last option, the one used for notification, essentially controls if and how the existing code is treated by ReSharper. For example, adding a redundant this. not only gets ReSharper to ‘gray out’ the redundant prefix, but offers extensive options for fixing the problem:

Quick-fix to remove this qualifier

Since this. is a piece of redundant code, ReSharper offers an extra option here to remove all redundancies. Naturally, both of the presented actions support the Fix in Scope mechanic, so they can be applied to the entire file, folder, project or solution.

In аdditiоn tо this mесhаniс, in RеShаrреr 10 yоu саn аlsо соnfigurе the insресtiоn right in that sаmе рор-uр mеnu. Yоu саn control insресtiоn severity:

Configuring ReSharper inspection severity

Note that, in the above, you can disable the inspection completely by choosing the Do not show option. It’s also worth noting that the above configuration feature applies to any kind of inspection, not just those related to code style!

Yоu саn соnfigurе the соdе style itsеlf, tоо!

Configuring code style inline

Оh, аnd if there’s а раrtiсulаrly wоrrying issue, yоu саn sеаrсh fоr it, аnd this аlsо fоllоws the Fiх in Sсоре mесhаniс insоfаr аs yоu’rе аblе tо sеаrсh fоr this type оf issue аt diffеrеnt sсореs:

Searching for similar issues

And while we’re on the subject of the Alt+Enter menu, check out a recently added option called Format Selection. Nothing to do with Code Style but still very cool (and yes, it re-formats the selected code according to your preferences):

Format code selection

One of the key aspects of code style settings is that, just like other ReSharper settings, you can share Code Style settings with your team, thereby enforcing a consistent style. You can find more info about settings here. Though, if you have been using earlier versions of ReSharper, ReSharper’s Options dialog has a separate item called Code Style Sharing for importing code style settings saved in ReSharper versions earlier than 6.1.

Now, for a look at some updates in ReSharper 10 specifically.

First of all, there are now settings for Attribute placement, so you can choose whether to keep attributes on a single line or several lines.

Code style attribute placement

ReSharper also got very smart about parentheses: even though it can detect redundant parentheses and eliminate them, ReSharper knows full well that sometimes you want to keep redundant parentheses so as to clarify the order of precedence, e.g., in logical operations. For this, we have a new setting:

Code style order of precedence

Furthermore, not only is ReSharper smarter in removing the parentheses, it can help you insert those that clarify the operations. This is what the nearby Add parentheses to avoid non-obvious precedence feature is for. First of all, you can specify what operators you want to clarify:

Code style add parentheses to avoid non-obvious precedence

And, with this setting, you can move to an expression, press Alt+Enter and ReSharper will insert the relevant operators for you:

Code style clarify precedence with parentheses

Finally, ReSharper lets you take control of access modifiers: you can now specify whether you want explicit or implicit private/internal modifiers, and you can also control the order of modifiers that you’d prefer to appear next to an identifier:

Code style modifiers order


This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

7 Responses to Code Style Settings in ReSharper

  1. Mike-EEE says:

    Team ReSharper, it would be great to see some innovation around this area. Namely, these settings should be turned into profiles that are customized per developer. These profiles then format the code that ultimately gets saved into the codefile and get checked into source control. The resulting format could (and should) be 100% StyleCop-compliant code.

    I have created a YouTrack issue here:

    Additionally, I also have a vote on Visual Studio’s site that has a bit more votes than YouTrack, and you can see that here:

    Finally, you can see a blog post that explains this in more detail here:

    Thank you for any consideration (and feedback!)

  2. JM Pirelli says:

    Nice !

    Not very important, but there is a typo in the parentheses / remove redundant parentheses setting: “if not clarifies prece n dence” => “if not clarifies precedence”

  3. Pingback: Dew Drop – February 4, 2016 (#2181) | Morning Dew

  4. Raeas says:

    This doesn’t really handle non-obvious precedence as seamlessly as I would hope. For instance, we want to ensure that developers use parentheses when they mix && and ||.

    if (a > b || b b || (b > c && d == 0)) or
    if ((a > b || b > c) && d == 0)

    The added parentheses make a big difference. However, in order to require this, it doesn’t just force parentheses when they are mixed, but will also require parentheses around individual parts of the statement, so we are forced to change this:

    if (a != b && c != d) to
    if ((a != b) && (c != d))

    This does nothing to assist with clarity, but only adds junk in the code (in our opinion). So we are forced to turn off the option that && and || have unclear precedence which leaves us vulnerable to the original errors.

    • razmik says:

      Thanks for feedback! We had some thoughts how to redesign that analysis, maybe even to split it up to more narrow ones. I’m not sure I could give some estimates, still gathering feedback and thinking on solution.

Leave a Reply

Your email address will not be published. Required fields are marked *