roslyn: Incorrect "use var" suggestion in a foreach loop

Version Used: 2.9.0-beta4-62911-02. Commit Hash: db5486576d92f24a62cf86406753d259ff148d83

Steps to Reproduce:

  1. Create a new console app.
  2. Add the following to an .editorconfig:
[*.cs]

csharp_style_var_for_built_in_types = true:suggestion
csharp_style_var_when_type_is_apparent = true:suggestion
csharp_style_var_elsewhere = true:suggestion
  1. Write this in the console app’s Main method:
            foreach (string arg in args)
            {

            }
  1. Trigger light bulb.

Expected Behavior: nothing is wrong here.

Actual Behavior:

image

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 19 (17 by maintainers)

Most upvoted comments

Muscle-memory isn’t really a factor in this particular bug. So it’s a bit of a non-sequitor right here.

In general though, it refers to how people tend to remember behaviors in an unconscious manner which they they repeat without thinking. In the context of Roslyn and the IDE, we talk about it a lot in terms of how people get used to typing. For example, without thinking i’ll often do something like List<int>ctrl-space,enter,list=new,space,tab knowing i’ll end up with the right set of code despite not necessarily thinking about each and every step and what it is doing. People get very used to these patterns and if you accidently make them do things that are subtly different, people will end up with different code than what all that ‘muscle memory’ led them to expect.

in general we try to avoid unnecessarily doing things that would impact the user in this way.

Such a situatoin does not exist here. This is a not a muscle-memory issue. This is a pure: “this is a bug” issue, with a very clear ‘right’ behavior and ‘wrong’ behavior.

Muscle memory issues are ones where the behavior has changed from a form that was previously thought to be correct to a form that is also thought to be correct, but which now behaves differently from the user’s expectations. These are particularly difficult to deal with because both before and after may be considered ‘correct’, but people are thrown off because of hte patterns and practices they’ve become accustomed to. As mentioned above, they’re also hard to fix precisely because you may now have a bifurcated user base where people who have been on a previous version of the product for many years becomes used to that style, and people on the current version then become used to the new style. So even trying to reconcile is likely to still impact some set of users.

That’s not the situation here. This is a pure regression in functionality unrelated to muscle memory. That someone invokes the feature using their muscles does not a muscle-memory problem make it 😃

We should fix this just like we would fix any sort of clear and obvious regressions in any feature area. We should prioritize it based on the severity for users. And we absolutely should discuss and consider how we can do better in the future in the change+review to try to prevent these regressions from happening. I would welcome ideas and brainstorming on how we could try to better defend against these sorts of things.