ReSharper/Rider Stuff

[dodexahedron]

For general talk about these tools, especially as everyone gets familiar with them.

Also intended for when someone finds something cool in them or their extensions which they think others might find useful.

[dodexahedron]

I'll start off by listing the ReSharper extensions I currently have installed for my ReSharper 2023.3.2 installation on the machine I'm on at the moment (I use pretty much the same set everywhere though).

• "Exceptional by MF" (not the other one with a similar name)
  • Provides inspections and refactorings regarding exceptions that aren't covered by ReSharper already. Has some nice stuff like suggesting that you document exceptions that can be thrown by methods and such that aren't handled within them, via use of the standard <exception> tag in the XmlDoc comments. Also follows that metadata as far as is defined and helps you, in general, write better XmlDoc OR helps ensure that you actually handle those exceptions.
  • Also allows some more granular treatment of exceptions than base ReSharper, such as telling it not to require it for members with certain access modifiers.
  • Also has a few inspections (some accompanied by refactorings) that help you write better exceptions and help you deal with exceptions better.
• "ReCommended Extension for ReSharper"
  • A bunch of additional inspections, rules, etc that are usually quite helpful.
  • Many of the features in this library end up making it into the next major release of ReSharper/Rider, too
• "Heap Allocations Viewer"
  • Inspections and a few refactorings to point out heap allocations, and sometimes even help you avoid/fix them.
  • Can be configured to only report those allocations which will happen in optimized builds (since debug builds get a LOT more, typically).
• "XML Doc Inspections"
  • Exactly what it sounds like - a collection of inspections centered around improving the quality of XmlDoc comments.
• "ReSharper Helpers"
  • An assortment of additional inspections and refactorings

All of these, as of this posting, are compatible with the current release of ReSharper.

There are several extensions in the gallery that are not compatible with current versions of ReSharper. This can mean anything from nothing at all up to "this will crash R# and potentially VS itself." So, don't use any that aren't marked compatible which, unfortunately, isn't something you can filter. Most extensions link to their project pages, so you can see if they're stale or not. In general, if they haven't been touched in the past year or so, there probably are issues. You can, however, sort by update date, to make it easier to know what's likely broken. The default sort in the extension manager for R# is popularity, which appears to only be a download count.

I also used to use "AsyncApostle," but haven't lately, because a lot of what it used to do, last time I had it installed, had been integrated into Visual Studio or ReSharper, so it was mostly redundant. It may still have some useful stuff or may have gained more since I last used it, of course.

[dodexahedron]

Something else neat about extensions is that, if they have configurable settings, they are handled through and stored in ReSharper's configuration mechanism.

So, if some extension is just super useful, but needs some settings modified to fit well with the project, those settings can be included in the same dotsettings files.

If someone does not have the extension corresponding to any XML element added in the configuration, ReSharper will simply ignore them. So, there are no problems if people use different extensions and configuration for one or more of them is in the shared dotsettings files.

[dodexahedron]

Also....

Since ReSharper itself is an extension....

Yo dawg, I heard you like extensions. So I put extensions in your extensions so you can extend while you're extending.

[BDisp]

ReSharper has many uses but VS2022 also has other very useful ones. One of them is automatic refactoring when we are repeatedly changing identical code, VS2022 suggests changes based on this pattern. ReSharper doesn't have it, at least it hasn't appeared to me. What's the most practical way to switch between the two without losing what each one has to offer?

[BDisp]

The only problem is that the text tab to make repetitive changes no longer appears and forces me to make all the changes without even a suggestion appearing. I'll first adapt before adding more complexity, but yes this might help, thanks.

[dodexahedron]

It's definitely configurable to not lose anything. Though, in some cases, they might provide a more poeerful version of a built in feature that just looks different or is invoked a different way. Type-, member-, block-, file-, folder-, namespace-, project-, and solution-wide operations when relevant.

There's a bit of an oboarding adjustment as you learn where stuff is and all that. But, once you get it all set up how you like, you'll really miss it any time you don't have it. 😅

[dodexahedron]

Another thing it will do is notice what you're doing if you're making a manual repetitive change and then give you a tip to press tab, which starts advancing through other occurrences and offering to perform the same action by just hitting tab again.

[dodexahedron]

This is done by some sort of heuristic, that's a black box, so it can sometimes not notice something that seems really obvious and other times might notice surprisingly complex stuff.

When it works, it's a great feature. When it doesn't, you'll be mad at it for not doing your work for you.

Or maybe that's just me. 😅

[BDisp]

Yes, I know that, but it's not showing up anymore. It could just be a coincidence. I will continue to pay attention to this situation.

[BDisp]

One thing I don't like on R# is when I want change a method it always add (); when it already exist. VS2022 is better on this case.

Assert.False (SomeBool);

When I change False to True R# replaces with:

Assert.True(); (SomeBool);

I always have to delete (); and this before this didn't happen.

[BDisp]

I already know why this happen. It's because of the space before the open parenthesis. If no space is used the this doesn't happen.
Before:
Assert.False(SomeBool);

After:
Assert.True(SomeBool);

If we really want to use the space then the R# has a bug in here because it must check if the first string available is a open parenthesis.

[dodexahedron]

This happens when you have both R# and VS performing completions. Behavior is basically undefined and you can get fun results like that.

I know it sucks to hear "it's your settings," but it's the truth. And, since both are such vast products, it's hard to narrow it down without seeing it live.

Heck, one of my machines has something ever so slightly different and it causes intellisense to not be displayed the same way or in the same cases, which is occasionally inconvenient if I want to see what overloads are available for a method in-place. I know that's a settings thing, too (after all, it's fine on my other machines), but I just haven't taken the time to fix it because it's such a minor issue and I'm usually deep into debugging something by the time it happens. 😅

And I won't fix it right now, either, because that machine is off and partially disassembled, right now, for some hardware upgrades. 😆

[dodexahedron]

I already know why this happen. It's because of the space before the open parenthesis. If no space is used the this doesn't happen. Before: Assert.False(SomeBool);

After: Assert.True(SomeBool);

If we really want to use the space then the R# has a bug in here because it must check if the first string available is a open parenthesis.

Hmm. I'm not married to that. I think it is in the current c# style guide, though.

One thing you could do if you like is take advantage of the virtual formatting feature. That lets you write it how you like, and displays it in your preferred style, while actually writing code that follows the team-shared settings.

That can take some effort to get all set up nicely, though.

As for R# being able to handle the space, it definitely can and does on my machines (except for the disassembled one, but that has a different root cause). It's usually just conflicting or redundant settings between VS and R#.

[BDisp]

After doing a cleanup code R# re-adds type name on object initializers. What I need to do?

Before:

        _contentOffset = new (-Math.Abs (offset.X), -Math.Abs (offset.Y));
        _contentView.Frame = new (_contentOffset, _contentSize);

After:

        _contentOffset = new Point (-Math.Abs (offset.X), -Math.Abs (offset.Y));
        _contentView.Frame = new Rectangle (_contentOffset, _contentSize);

@dodexahedron can you add some configuration so R# doesn't change this please.

[BDisp]

The version is:

JetBrains ReSharper 2023.3.3

Build 233.0.20240117.105338 built on 2024-01-17

ReSharper
2023.3.20240118.163204 (up to date)

Environment

Visual Studio Community 2022
Version 17.9.2, InstanceId 2a35984b

[BDisp]

This is the configuration that is used on the ScrollView.cs where I still having formatting issues because the Rectangle and Point types are always added after the new. Is there any erroneous configuration? I already deleted all the .DotSettings.user files. I would like to fix this, otherwise my cleanup code will have a bunch of changes because of this. Thanks.

[BDisp]

Only with the bellow change I got this working now.

[dodexahedron]

Ah. That's the "when type not evident" part, which is there to just make it easier to read in some cases by including the type when nothing else on the line makes it visibly obvious what type is being constructed.

I agree that can probably be turned off for us, since it's nearly always going to be the same 5 or so types.

I'll check the team shared settings and adjust if necessary.

[dodexahedron]

Ok, I made tweaks.

Try cherry-picking 00f70e3 or merge that branch into yours or however you want to do that to get the changed file.