Looking for feedback on some formatting changes
We’re considering making two changes to the way the formatting engine works, based on feedback we’ve received from Beta 1. I’d like to post them here, and see what you all think of them, to make sure we’re making the right decision.
Change 1: Comments that start at column 1.
In Beta 1, if you have a comment that starts at column 1 (the very left edge of the screen), we won’t change it’s indentation. The main reason for this behaviour is that if you select a block of text and use Edit->Advanced->Comment selection, we place all the ‘//’ that we generate at the left edge, and we wouldn’t want a subsequent formatting to push them way in.
We’re finding that this behaviour has bad effects in two main ways.
- It’s confusing. It’s not really clear why we change the indentation of some comments, but not others.
- It has a negative effect on generated code. Often it’s nice to be able to generate some code with comments in it(say with a snippet). But it looks kind of ugly if either all you’re comments end up at the left margin, or you need to add spaces to the snippet file.
Our proposed solution to this is to make the formatting engine always indent comments, and fix our “Comment Selection” behaviour to generate comments at the indent of the line with the least indentation in a block. For example comment selection would now generate something like this:
public void Method()
{
List<int> list = new List<int>();
li.Add(3);
//foreach (int i in list)
//{
// Console.WriteLine(i);
//}
}
Instead of:
public void Method()
{
List<int> list = new List<int>();
li.Add(3);
// foreach (int i in list)
// {
// Console.WriteLine(i);
// }
}
Change 2: Anonymous methods default to having the open brace on the same line.
This change is mainly for readability. Basically we want to change the default value of “Tools->Options->Text Editor->C#->Formatting->New Lines->New line options for braces->Place open brace on new line for anonymous methods” from true to false. The reason for this is that we think that if you have code like this:
List<Thing> things;
void SomeMethod()
{
List<Thing> somethings = things.FindAll(delegate(Thing thing) {
return thing.ShouldBeIncluded;
});
}
It’s easier to tell that it’s part of an anonymous method than:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; }
);
Or:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; });
Or:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{
return thing.ShouldBeIncluded;
});
All of which look sort of like you just have a random block.
So what do you think? Are we on the right track, or is there a better way to solve these problems?
Comments
- Anonymous
July 09, 2004
Change #1:
I've been meaning to say something about this. Not indenting the comment marker for commented out sections causes grief, since when the section gets re-formatted, the comments are indented and the original indentation is included in the comment.
The way of placing the comment markers after the tabs is best.
Change #2:
I don't like either one. How about:
List<Thing> somethings = things.FindAll(
_ _ delegate(Thing thing) {
_ _ _ _ return thing.ShouldBeIncluded;
_ _ });
This depicts the anonymous method as close as possible to a normal method.
If you have more parameters, you could do:
List<Thing> somethings = things.FindAll(myParam,
_ _ delegate(Thing thing) {
_ _ _ _ return thing.ShouldBeIncluded;
_ _ },
_ _ myParam2, myParam3);
Making anonymous methods 'jump out of the code' is essential, IMO. - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
Here's a tip for putting code into a blog post: Type the code in VS. Copy and paste it into Word, then copy and paste it into the blog page. - Anonymous
July 09, 2004
Really, you want VS to not change the formatting on comments made with the auto-comment function.
So, why not add a globally useful feature: Have VS store formatting in a special comment at the end of the file. Then VS can act on more than just what the code looks like.
Although, I'm guessing no one will like this, precisely because VS will be acting on more than the code looks...
My vote would be to have the autoformating for all comments, regardless. - Anonymous
July 09, 2004
Kevin,
About the blog post thru MSWord: This doesn't work in comments because HTML is reformatted to plain text.
For instance: <b>not really bold text</b>. - Anonymous
July 09, 2004
I like your autoformatting idea for comments. I've always wished VS did something like this, since I also find the comments at the very left (or worse, ragged comment lines) to impair readability.
I'd rather have braces on their own lines for anonymous methods (as well as anything else), but I might change my mind after I use anonymous methods. - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 09, 2004
The comment has been removed - Anonymous
July 10, 2004
Thanks, Ben. So what you are saying is that you like anonymous methods formatted the way they currently are, see my 4th example. We would definitely not be changing the ability to do that, just what the default value of the option is "Tools->Options" is.
Based on this feedback however, it looks like we may want to leave the default alone. - Anonymous
July 10, 2004
Stupid question from a VB guy: Why doesn't C# use /* ... */ for block comments? Wouldn't that render this question moot? - Anonymous
July 10, 2004
Phil, because then you can't block comment anything that contains a /* */ style comment, because the new comment that you introduce would end at the first */ - Anonymous
July 11, 2004
The comment has been removed - Anonymous
July 11, 2004
Kevin,
Regarding Change 2, I was agree with most of the others and format it like you have in example D. IOW, keep the default as currently defined. - Anonymous
July 12, 2004
The comment has been removed - Anonymous
July 27, 2004
If the underlying requirement is to show anonymous methods clearly, would it be feasible to actually colour code them? E.g. a subtle background shading for anonymous blocks?