Incorrect formatting of C# comments

[vsfeedback]

When you want to disable (but not delete) a field etc in a C# class, you comment it out by writing "//" at the start of the line, but this causes VS 15.8.0 to incorrectly format the line when the previous line ends with a comment. You can understand this much easier when you look at my screenshot attached.

To reproduce this bug, first put this class in a .cs file:

class ExampleClass1
{
    int ExampleField1;
    int ExampleField2;  // Some comment here.
    //int ExampleField3;
    int ExampleField4;
}

Then select the text (select the entire class). Then click menubar -> Edit -> Advanced -> Format Selection. VS changes the class to:

class ExampleClass1
{
    int ExampleField1;
    int ExampleField2;  // Some comment here.
                        //int ExampleField3;
    int ExampleField4;
}

The bug also occurs when VS formats the class at other times, not only the "Format Selection" command. See the "Automatically format when/on XXXXX" options in menubar -> Tools -> Options -> Text Editor -> C# -> Code Style -> Formatting -> General.

Thanks for investigating this!

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/317225/incorrect-formatting-of-c-comments.html
VSTS ticketId: 668245
These are the original issue comments:

Etienne Poirier on 8/21/2018, 04:35 PM (2 days ago):

Same issue as

https://developercommunity.visualstudio.com/content/problem/20554/line-comments-unwantedly-align-to-comment-above-in.html

Thank you to check this.

These are the original issue solutions:
(no solutions)

[CyrusNajmabadi]

This seems by design to me... it's a common pattern to have multi-line comments at the end of constructs, and to align them across multiple lines.

In this case, we don't really have any way to know or believe that this isn't one of those cases, and aligning the comments as shown seems reasonable in terms of respecting the common pattern that is out there.

[verelpode]

This seems by design to me...

I can't really agree with you because VS 15.8.2 also does it when the first comment is single-line // and the second comment is multi-line /* */
The following shows the result after executing the "Format Document" command:

int ExampleField2;  // Some comment here.
                    /*
                    int ExampleField3;
                    int ExampleField4;
                    int ExampleField5;
                    */

I don't believe that anyone wants the above formatting.

it's a common pattern to have multi-line comments at the end of constructs, and to align them across multiple lines.

I never do that, and apparently multiple other people also never do that, therefore I suggest making a checkbox in the Options window, so that people can simply switch this behavior on or off as desired.
However, in my opinion, the mixed example above seems to be a bug not a feature.

[dibarbet]

@sharwell do you recall if there was an outcome for this in design review, or does it still need to be discussed?

[sharwell]

@dibarbet This one is still in the queue

[dibarbet]

Thanks for confirming, wanted to make sure. I'll park these 2 until the next meeting then.

[sharwell]

I'm bringing this to a design review today. My proposal is as follows:

• The current behavior is generally by design

• We could modify the current behavior in the case where a line comment starting with a space is followed by a line comment not starting with a space:

  int x; // This comment starts with a space
         //This comment did not start with a space

  For this case, the first line comment not starting with a space would be aligned with int instead of the current behavior of aligning it with //.

[CyrusNajmabadi]

Note that some linters will complain if you don't start your comment without a space.

[sharwell]

@CyrusNajmabadi Other linters will complain about comments at the end of a line of code. Most relevant to this issue though is the fact that most cases where I've seen this reported as a bug, including the original example above, do not have a space on the line of code that the user did not want to see indented.

[verelpode]

most cases where I've seen this reported as a bug, including the original example above, do not have a space on the line of code that the user did not want to see indented.

That's an interesting pattern observation, but I think you'd like to see this issue fixed and terminated forever, but I fear that if the solution relies upon whether or not that particular space character exists, then it will be precarious and this issue will in future again be reported as a bug, instead of being laid to rest permanently. Did you dislike the idea of solving it via a tickable option in the Options window?

Another case to remember is mixed comment types, such as the following example. The solution for mixed comments appears to be simple and unambiguous and does not require an option in the Options window. If the second comment is a different type than the first comment, then the second comment should never be indented to match the first comment, thus VS should never produce the following:

int ExampleField2;  // Some comment here.
                    /*
                    int ExampleField3;
                    int ExampleField4;
                    int ExampleField5;
                    */

[CyrusNajmabadi]

My personal opinion is that your behavior appears to be unethical

It's unethical to provide support to people to show how they can contribute to the Roslyn open source project?

Being an app developer (or likewise) is already a challenging, time-consuming, and exhausting job. Thus it would be very unreasonable to expect app developers to do even more work in the form of unpaid casual side-jobs

This is how much of the open source world works. Projects are made freely available for people to use and modify and contribute back to. When the priorities of the team don't align with your particular desires, you can choose to petition that they change, and/or you can choose to contribute your own efforts to align the project with your own desires.

However, it would be wildly unreasonable to expect @ChainReactive to sacrifice himself like you do.

I have never expected @ChainReactive to do anything. I have simply pointed out that this is something he can choose to contribute to if he wishes. And, if he does wish to do so, i am 100% willing to provide my own time and experience toward aiding that effort. There are many other community members who are willing to do that as well, and this has led to hundreds of community PRs and thousands of commits to the Roslyn repo that have improved the project for everyone. This is the power and value of it being an open source project.

Cheers! :)

[CyrusNajmabadi]

Sacrifice ethical behavior.

Working with a community to improve an open source project sacrifices no ethical behavior as far as i can tell.

[verelpode]

@CyrusNajmabadi

It's unethical to provide support to people to show how they can contribute to the Roslyn open source project?

You've been doing more than that. You're free to follow your choice of religion/philosophy, and various people such as @ChainReactive, myself, and others are free to follow our own choices of religion/philosophy. It's unethical and inappropriate if you frequently try to push or manipulate forum participants into joining your religion/philosophy.

If I followed your recommendation and adopted your religion/philosophy, then it would substantially damage the upbringing of my children. That would be even worse than unethical -- it would be monstrous to harm my children in that way.

[CyrusNajmabadi]

It's unethical and inappropriate if you frequently try to push or manipulate forum participants into joining your religion/philosophy.

Continuing to offering help is not pushing religion. Nor is it unethical to provide free support to people who can choose to take it or not.

If I followed your recommendation and adopted your religion/philosophy, then it would substantially damage the upbringing of my children.

Then don't. Nothing about what i've said insists that you do this. It merely offers you the choice of doing this. It's not unethical to make ones time available to help people freely if they are interested. I do this in many avenues in life. I freely offer tutoring for many different subjects. I freely offer assistance with learning different programming languages. I freely offer time and information toward contributing to some FOSS projects.

it would be monstrous to harm my children in that way.

So you're saying i'm operating unethically for offering my time and knowledge to people who may want it because if you were to take me up on it it would hurt you? Does that not strike you as ridiculous?

Should i also not offer free tutoring for interested students because if some were to take it they might be negatively impacted in other avenues of life?

Does it not make more sense (and seem more ethical) to have this be available and to leave it entirely to you (and others) to decide if you want to take it or not? I don't see how this is at all a religion, but i certainly can see how it's a philosophy. And it's a philosophy that has worked well for dozens of people out there. I think it's a good thing that I can help out, and I'll continue to do so and will continue to announce this possibility so that if there are people out there (even if its not you) will know and can take advantage of it if they wish.

Cheers!

[CyrusNajmabadi]

@verelpode @ChainReactive I'm not sure what else can be stated at this point. The team has put forth their position on this issue and how it is currently prioritized (i.e. in the help-wanted bucket). I'm available to help out if you, or anyone else, is interested in tackling this from the community.

As a FOSS project, Roslyn thrives on shared efforts by dedicated teams at MS, outside of MS and from community efforts. It's part and parcel of that that not all work is done internally. There is effectively interest from many thousands of individuals and groups about what is important, and the way Roslyn effectively manages that is to make it so that the core team itself is not the limiting factor for improvements happening. This is a virtue of the project, and one of the very specific reasons it is open source.

At this point, i don't think I can add any more help here. My offers of assistance seem to not be welcome, and the discussion seems to not be providing any actual value toward solving the originally reported issue.

If anyone is interested in solving this issue in the future, see the links provided above for a large group of community members (internal and external) and resources that can help out here.

Thanks all!

[HappyNomad]

@CyrusNajmabadi

You have a knack for justifying inaction.

I've already offered my time toward helping you fix this in a paired manner. If you view my willingness to work with you to fix hte issues you care about as "inaction" then that's on you.

I was talking about the Microsoft team's inaction on this bug, not yours. You seem strangely passionate about defending their inaction.

To be clear, I think that contributing to open source is a wonderful and worthy endeavor. We need more of that sort of collaboration in society. But as @verelpode pointed out, we all have a finite amount of time and other priorities in life. When it comes to side projects, we have to be selective about what we say yes to. We might have time to contribute to some but not others. I think it's unreasonable to say that, because I'm a Visual Studio user and want a bug fixed, I must go down the rabbit hole of learning Roslyn.

While I appreciate your offer of assistance, I fail to grasp the practical value of it. We're all programmers here. If I'd go to the trouble of learning Roslyn then , for such a small improvement, I may as well figure it out myself. If you sincerely want to help, rather than just pay lip service to the concept of helping, then please just fix this bug.

[jaredpar]

@verelpode please keep your comments on topic here.

[jaredpar]

As @sharwell and @CyrusNajmabadi have already elaborated on, the Roslyn team considered this bug, discussed the impact and potential solution in design meetings, and while they did arrive at a path forward decided pursuing it simply fell below their priority bar.

The IDE team, as well as pretty much every other team, has a full load of work on their plate. Fixing this bug means there is another bug, which they value higher, that they cannot fix. In this case they've chosen to prioritize other work on their plate. At the same time they're willing to assist anyone else who wants to pursue the fix.

@ChainReactive @verelpode I understand the frustration here at a bug that you prioritize not being fixed. At the same time though the IDE team has not been dismissive of your concerns. Rather they've given it careful thought and devoted design time to coming up with a potential solution.

[YxT3]

▪ Two years on, or three actually, and no matter how many eufemisms, mental turnings and twisted answers invented, my impression remains that CyrusNajmabadi's and Sharwell's early responses to this question ( not to mention M$'s misbegotten core position in this issue ) have been disappointing, seemed more like a denial of the problem, maybe blinded by half cooked work-arounds, it even seemed as made/written by non-programmers.

▪ Essentially this issue came into existence with VS.2017 (v15). Up to and including VS.2015 (v14) we had no such problem.
Makes you wonder what could have been the problem for M$, preventing them from taking a [configurable] step back in this ?

▪ An expensive solution can be found in JetBrains ReSharper. On Visual Studio 2022 (v17) I stumbled into this darn "End-of-Line Comment vs Next Line Comment Reformatter Alignment" problem, to ultimately find a true solution in ReSharper 2021.
Is this a M$ attempt to indirectly promote a JetBrains product ?

▪ This Comment Reformatting issue also flashes me back to the intelliSense Popup Height statically having been reduced in Visual Studio 2010 (v11) – a problem also resolved by ReSharper, a decade ago.

▪ Looking even wider, these situations may have similarities to Embarcadero's RAD-Studio and FreePascal's Lazarus being unable to implement Undo/Redo in their Visual Design environments.

[CyrusNajmabadi]

@YxT3 I'm not sure what you are looking for here.

We've looked into the issue and prioritized it accordingly. I've mentioned my willingness to personally spend my own off-work time to work with interested community partners to make changes here.

I get that you would like us to prioritize this higher. However, understand that that's how everyone feels about their particular issues they care about. We invariably have to make calls as to what to work on, and that means some people will not get the changes they want.

The benefit of being open source here is that customers who do really want changes that don't meet our priority bar can then contribute those changes themselves. We have dozens of developers who have done this, and we often put on special effort (including our own spare family time) to make this happen.

Let me know if you're interested in working with us on this. It is near the holidays, but I will take time out from my off time to help out.

Thanks!

[CyrusNajmabadi]

@verelpode This is an open source project. And, like most projects, it must pick and choose what can make any release. Not every issue will make it, and cuts and prioritization will mean that things at lower priority may take a long time until eventually getting resolved.

However, as i mentioned above, the value of open source is that if community members do feel interested in contributing, and they have the time and preference to do so, then that is a possibility available. Unlike a closed-source project (where a low priority issue might never be resolved), in an open source project there are other paths available.

This does not mean that someone should do this if they don't have the inclination or time available. I never said that. I only said that if someone was interested and could spare time for this that we would absolutely help make this happen. I'm personally spending time with my family right now. However, i would absolutely be willing to still make the time happen to work with you (or anyone else interested) in coming up with a plan and a PR to address this issue (and others that we haven't been able to fit into our schedule).

This is neither unethical or inappropriate. It's precisely the nature of software projects, especially those that are open source.

[CyrusNajmabadi]

@verelpode I'm a developer on this team. I'm explaining the situation as it stands. Right now this issue is on our backlog. Meaning there are many other issues we consider more important that we will be prioritizing ahead of this for our upcoming releases.

People have shared their thoughts that htey are bummed that this isn't getting attention. I'm providing information on what are viable avenues available to see progress on this in the meantime if people want this to be fixed in a shorter timeframe.

Working on open source projects is neither illegal or unethical. The Dotnet org works with hundreds of people globally in these projects. I myself have contributed many times voluntarily. Precisely to see things changed that i personally cared about, but which the team could not find time for.

I get that you want this issue to be fixed. However, as you can see, this repo alone has over five thousand active issues that require our attention. No matter what, we must pick and choose what we think is important and what order to process that in.

If you are interested, i'm happy to work with you to come to a resolution on this issue. If you cannot make the time, i completely understand and would not ask you to give up something you consider important yourself to do this. However, there may be others in teh community who are very interested and who are willing to work on this sort of stuff. As before, we're always welcoming of this. And i know several on the team (myself included) who will do what it takes to make that succeed.

[CyrusNajmabadi]

Note: @verelpode I'm happy to discuss this further (including face-to-face) on gitter.im/dotnet/roslyn, or discord.gg/csharp.

[CyrusNajmabadi]

Closing out as the original use case was fixed. If you just comment that code out and format you get:

[rajko-horvat]

This seems by design to me... it's a common pattern to have multi-line comments at the end of constructs, and to align them across multiple lines.

In this case, we don't really have any way to know or believe that this isn't one of those cases, and aligning the comments as shown seems reasonable in terms of respecting the common pattern that is out there.

Well, this default aligning behavior has never been helpful to me.
I would like the option to completely disable (or enable) the beforementioned behavior. That would completely solve problems for people that don't need this type of behavior.

[rajko-horvat]

Wait, here is another alternative solution, better than my previous brainstorming. VS would only increase the indenting of a comment if it is already indented by at least one space or tab char. Example:

int x;  // First comment.
    // VS would align this comment with the first comment because it is already indented.

int y; // Blah blah.
// This comment would never be aligned with the previous comment.

Thus the final result is:

int x;  // First comment.
        // VS would align this comment with the first comment because it is already indented.

int y; // Blah blah.
// This comment would never be aligned with the previous comment.

In other words, if a comment is aligned with "int x;" then it remains at that level, but if it already indented beyond "int x;" by one or more space or tabs, then VS aligns it with the previous comment.

Not true for VS 2022 17.8.2