Visual Studio 2022 incorrectly formats code with parameterized types

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work]
Visual Studio 2022 removes spaces before the angle bracket of parameters types. For example, the line of code
int value = SomeFunction <int> (someParameter);
gets reformatted as
int value = SomeFunction<int> (someParameter);

This is incorrect. It is objectively wrong to not put a space before the < punctionation mark. If you want to allow people to opt-into the wrong way of formatting the code, then fine, but don't force the wrong way onto people.

There is no option in C# format spacing to include a leading space before angle brackets. This needs to be added, or better yet, just default to the correct formatting.

Given how frequent type parameters are used, this incorrect formatting makes Visual Studio's format code feature unusable.

---

Original Comments

Feedback Bot on 5/2/2025, 09:52 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Feedback Bot on 5/5/2025, 05:40 PM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

Deepak Rathore (ALLYIS INC) [MSFT] on 7/11/2025, 03:22 PM:

Thank you for providing feedback, and we’re sorry to hear it’s not behaving as you expect. Based on your description so far, we were unable to reproduce the issue. Could you please upgrade to latest version of Visual Studio and try again. If the issue persists, please let us know

Anonymized GDPR on 7/11/2025, 04:48 PM:

(private comment, text removed)

Bob Jones on 11/5/2025, 05:56 PM:

Muhammad Nabil Fikri Adenan (Centific Technologies Inc) [MSFT]

It’s obvious that your “need more information” is a lame attempt to get your ticket system to automatically close the ticket. The problem is EXACTLY what the OP states. The code formatter does NOT put a leading space before the open angle bracket. Yes, this does happen if you run “autoformat code on paste”. It also happens if you use the keyboard or menu bar to format the code.

There is literally no more information you can possible need or get about this problem. If Microsoft is too lazy to fix one line of code in the code fomatter, then at least have the honesty to admit you are not going to fix it because you don’t want to rather than you just don’t understand what the problem is and you need more information to figure it out.

Microsoft’s refusal to even attempt to fix bugs in Visual Studio is exactly why VS gets a bad rap. If a customer takes the time to hand you a bug on a silver platter, the least you can do is attempt to fix it instead of trying everything to weasle out of scheduling a bug fix.

This is literally a one-minute fix. If I had access to the Visual Studio code base I’d have it fixed already. It cannot be hard to change the rule from “zero spaces before angle bracket” to “one space before angle bracket”. You have spent way more time trying to get out of addressing this bug than it would take for one of your developers to actually fix it.

The worst thing a software company can do is play games with its bug tracking to make it look like there are fewer bugs by having them returned for fradulant reasons rather than fixing the bug. And using an automated closure system to get rid of the report of a bug you don’t want to fix is quite shady. It does not instill confidence in you customers.

This bug was literally posted seven months ago and you couldn’t find any time in the past half year to fix one line of code? This is ridiculous.

Feedback Bot on 7/11/2025, 04:53 PM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

Muhammad Nabil Fikri Adenan (Centific Technologies Inc) [MSFT] on 10/13/2025, 04:01 AM:

Thank you for taking the time to log this issue!

I would like to confirm if your issue is as showned in the gif below:

if not, In order to investigate your issue further, can you help to confirm several questions?
1. Could you try to update your VS to latest build?
2. Can you provide us a repro video using https://www.screentogif.com/ or a similar tool?

(The reason we’re asking for additional information is that we’d like to fully understand the issue and try to reproduce it on our side.)

We look forward to hearing from you!

Feedback Bot on 10/22/2025, 06:07 AM:

We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.

Bob Jones on 11/5/2025, 05:58 PM:

And yes, this does occur with the LATEST VERSION OF VISUAL STUDIO.

The bug isn’t going to magically go away.

Muhammad Nabil Fikri Adenan (Centific Technologies Inc) [MSFT] on 11/6/2025, 02:53 AM:

Thanks for your sharing the detail steps, I can reproduce this issue through your shared steps and this issue has been escalated for further investigation, if there is any process, I will inform you immediately.

[CyrusNajmabadi]

This is incorrect. It is objectively wrong to not put a space before the < punctionation mark. I

Formatting is ultimately subjective. We've formatted generics consistently in this fashion in C# since we introduced them 20 years ago in C#2.0. Given the lack of feedback on wanting generics to be formatted differently, we're duping this against #31691. It's not something we'd provide an option on (too niche). But a formatting extension api would allows for this.

[hodorstorm]

This is clearly not the same issue as "Design a formatter extension API #31691 on Nov 26, 2025"

This looks like someone trying to sweep a bug under the rug. The OP is right. There should be an option to have a space before angle brackets as there is already options to have a space before square and round brackets. The other Rosyln Issue requests having the ability to create arbirtary rules via an API, which is orders of magnitude more complicated. This issue should be re-opened as the "close as a duplicate" was clearly not an honest action.

[CyrusNajmabadi]

There should be an option to have a space before angle brackets

Such an option could be added with a formatter extension api.

which is orders of magnitude more complicated.

This is equally complicated.

as there is already options to have a space before square and round brackets.

Those are implemented with rules, which is what the formatter extension api would be providing, so that it can be provided by the ecosystem/community.

This issue should be re-opened as the "close as a duplicate"

This is a duplicate of the core issue. Our position is that these requests are ones which should be provided through an extensibility api.

[hodorstorm]

There should be an option to have a space before angle brackets

Such an option could be added with a formatter extension api.

The options to add a space before square and round brackets are already in the formatter without any extensions. It makes no sense to put this as an API. You are overly complicating the solution and making it inconsistent.

which is orders of magnitude more complicated.

This is equally complicated.

No way. Using an API instead of a .editorconfig rule or the built-in dialog for formatting rules is way more complicate to implement (and will take way longer to do) and it is way more difficult for the user.

as there is already options to have a space before square and round brackets.

Those are implemented with rules, which is what the formatter extension api would be providing, so that it can be provided by the ecosystem/community.

The implmentation of angle brackets should be the same as for round and square brackets. Is would be obviously more consistent.

This issue should be re-opened as the "close as a duplicate"

This is a duplicate of the core issue. Our position is that these requests are ones which should be provided through an extensibility api.

Basic features should not require using an API, especially one that is likely to never come. Your judgement is wrong. Any user would expect to see an option for angle brackets in the same UI as the options for square and round brackets. Doing otherwise violates the principle of least astonishment and makes changing the behavior far more difficult than simply clicking a checkbox under "options".

[CyrusNajmabadi]

The options to add a space before square and round brackets are already in the formatter without any extensions

That formatter is not changing, due to changes there nearly always causing regressions. We want to build an extension api with which we can reimplement things that would then allow for this functionality.

It makes no sense to put this as an API.

It does as that then allows expanding functionality without requiring revising the core engine itself.

Using an API instead of a .editorconfig rule or the built-in dialog for formatting rules

I don't think you understand. The extension api wouldn't preclude editroconfig or a dialog. It woudl just allow new rules to be provided without having the change the core engine like today.

It's not 'instead'. It's just the way the new engine would be written. There would be a core engine that loads in the rules and exposes an api. And all existing rules would be written on top of that api. new rules could be written using the same system.

The implmentation of angle brackets should be the same as for round and square brackets.

The implementation for braces and brackets is severely problematic and nearly always causes regressions when touched. We are not changing the existing formatting engine because of this as it has caused major problems many times as people have tried this. The new system allows the core engine to stay unchanged, while allowing new rules to be added safely.

especially one that is likely to never come.

I think it is likely we will get this api.

Any user would expect to see an option for angle brackets in the same UI as the options for square and round brackets.

Yes. I agree. And that's something the formatting api proposal would enable.

and makes changing the behavior far more difficult than simply clicking a checkbox under "options".

Yes. I agree. And that's something the formatting api proposal would enable.

The point is that instead of having a hard coded engine that is brittle, and which breaks people every time people try to modify it, we instead build an engine designed for extension from the beginning, and reimplement the rules on top of it.

It would then be trivial to add support for this new rule including by us, or by someone else if we don't do it.

[CyrusNajmabadi]

Note: the designs we have here make the rules nearly all textual. So instead of just a random named rule, whose logic you cannot control, the rules actually are specified as text, stating declaratively what they do. Which means adding a rule like you want literally would just be copying the existing rule, but making it apply to certain other nodes or tokens. These would then show up in UIs/editorconfig/etc. That's literally the point of a formatting extension api.

[hodorstorm]

So instead of doing a five-minute fix that would levage the existing options dialog, you are going to make everyone wait for the minimum of a year -- if it ever gets done -- for a more complicated solution that's so burdensome that no one will use it. Not a good decision. This is why people are switching to JetBrains Rider. It just works. No hassle.

[CyrusNajmabadi]

So instead of doing a five-minute fix

It's not a 5-minute fix. that's my point. We have many examples of people (internal and external) trying to make formatting changes, and then regressing things for some user, leading to painful rollbacks, and times when the ecosystem has to deal with varying sdks formatting code in inconsistent ways.

for a more complicated solution that's so burdensome

It's less complicated. That's the point. Instead of having all the logic gooed up together like it is today, having a core engine that allows for simple rules to declare and validate, we can have rules like this be added safely and easily.

At this point i feel like the posts are not being written. Despite clarifying numerous times that this is about a better designed formatting engine that can ship new rules without risk, you keep insisting this is something else entirely and being adamant that we go the route that we have seen does not work over and over again. I'm going to lock this as this is not leading anywhere.