proposed set of editorconfig in visual studio for C# and Visual Basic

[Jonathon Marolf]

Hello editorconfig community

I am a developer at Microsoft working on the IDE for C# and Visual Basic in Visual Studio.

I am currently planning to add editorconfig support for most of the C# and Visual Basic formatting options in Visual Studio.  Note, the plan is to eventually add these same options to projects like Omnisharp so they would be supported in other places besides Visual Studio. I would love to get feedback from all of you on how well my proposed set of options fits into rest of editorconfig and what changes you would like to see.

here is the gist with my proposed set of options

I look forward to your feedback.

Thanks,

Jonathon Marolf

[Hong Xu]

On 2016-11-02 Wed 18:35 GMT-0700, 'Jonathon Marolf' via EditorConfig <editor...@googlegroups.com> wrote:

> Hello editorconfig community
>
> I am a developer at Microsoft working on the IDE for C# and Visual Basic in
> Visual Studio.
>
> I am currently planning to add editorconfig support for most of the C# and
> Visual Basic formatting options in Visual Studio. Note, the plan is to
> eventually add these same options to projects like Omnisharp

> <http://www.omnisharp.net/>so they would be supported in other places

> besides Visual Studio. I would love to get feedback from all of you on how
> well my proposed set of options fits into rest of editorconfig and what
> changes you would like to see.
>

> here <https://gist.github.com/jmarolf/0e165b27a498b49e3b3512004ea9d8b8>is

> the gist with my proposed set of options
>

Hi Jonathon,

Thanks for your work, it is definitely very valuable for the
EditorConfig community. I personally won't be against the proposal you
have attached; but the core of the EditorConfig community won't touch
the very language specific options.

For the option dotnet_sort_system_directives_first, can you give us an
example of how it would work?

Thanks,
Hong

[Trey Hunner]

Hi Jonathon!

I second Hong's thought that EditorConfig won't personally be adopting these options as official, but I think it still makes sense to discuss how they fit in with other options and whether they conform to typical EditorConfig conventions.

One difficulty I'm having in judging how the options feel is that you're doing a couple things we haven't done yet (hierarchical keys, multi-valued options, etc.). If others invent options that require similar needs in the future, it would be convenient if we could recommend a common convention for handling these cases.

So looking at the Gist...

I'm pondering the `;` in INI values and the `.` notation for making a hierarchy in INI keys.

I'm mostly curious about the thought that went into those decisions because I haven't seen the EditorConfig format used in a similar way yet.

What was the reason for choosing `;` over `,` or other separators? Have you found pre-existing INI conventions for multi-valued INI properties or did you need to invent a convention from scratch?

I haven't dealt with hierarchical INI keys before. Is `.` common for INI hierarchies? Did you choose that format because it seemed more variable-like (in many OOP languages at least)?

How will the options in the Code Style Options section work? Is both `true`/`false` and another option provided in the same key? How does that look? Is a `;` used?

Any other things I may have missed asking about?

-- 
Trey Hunner
Technical Trainer, Teacher
http://treyhunner.com

[Jonathon Marolf]

EditorConfig community won't touch the very language specific options.

That makes sense as was what we were all expecting

For the option dotnet_sort_system_directives_first, can you give us an example of how it would work?

This option is for the imports/using at the top of a given code file. Most of the base-class-library namespaces start with System. Some people prefer to sort their usings alphabetically, some prefer them sorted alphabetically except for System namespaces.

This is the top of a C# file with it on:

	using System.Collections.Generic;
	using System.IO;
	using System.Threading;
	using System.Threading.Tasks;
	using StreamJsonRpc;
	using Microsoft.CodeAnalysis.Remote;

And this is it with it off

	using Microsoft.CodeAnalysis.Remote; using StreamJsonRpc; using System.Collections.Generic;
	using System.IO;
	using System.Threading;
	using System.Threading.Tasks;

[Jonathon Marolf]

`;` in INI values

There was some discussion on the team on whether `;` or `,` would be better separators.  `;` seemed a more in-your-face separator than `,` which, since this is a weird new thing we are doing, adding multiple options, seemed like a good idea. I am not aware of any INI format that chooses one over the other, but will happily look into that.  Are you aware of any problems in other editorconfig parsers with this notation?

`.` notation for making a hierarchy in INI keys and INI hierarchy in general

Naming styles need to be hierarchical in some way.  Normally INI files specify hierarchy like this where you have some [header "name"] and then later specify this under [header] like you do for difftool in gitconfig.  Would this be preferable?  Wouldn't it be ambiguous with editorconfigs globs for files?  I can't say I am in love with the current syntax, but I was unable to find anything clearer without being ambiguous with other options.

How will the options in the Code Style Options section work? Is both `true`/`false` and another option provided in the same key? How does that look? Is a `;` used?

The thinking is that it would look something like this:

csharp_style_this_qualification_for_field = true;warning

csharp_style_this_qualification_for_field = false;warning

It might make more sense for this to be yes/no instead of true/false. As false implies doing the opposite (not wanting a `this` to qualify fields and giving a warning when that happens). I'll update the gist.

On Thursday, November 3, 2016 at 12:43:34 PM UTC-7, Trey Hunner wrote:

Hi Jonathon!

I second Hong's thought that EditorConfig won't personally be adopting these options as official, but I think it still makes sense to discuss how they fit in with other options and whether they conform to typical EditorConfig conventions.

One difficulty I'm having in judging how the options feel is that you're doing a couple things we haven't done yet (hierarchical keys, multi-valued options, etc.). If others invent options that require similar needs in the future, it would be convenient if we could recommend a common convention for handling these cases.

So looking at the Gist...

I'm pondering the `;` in INI values and the `.` notation for making a hierarchy in INI keys.

I'm mostly curious about the thought that went into those decisions because I haven't seen the EditorConfig format used in a similar way yet.

What was the reason for choosing `;` over `,` or other separators? Have you found pre-existing INI conventions for multi-valued INI properties or did you need to invent a convention from scratch?

I haven't dealt with hierarchical INI keys before. Is `.` common for INI hierarchies? Did you choose that format because it seemed more variable-like (in many OOP languages at least)?

How will the options in the Code Style Options section work? Is both `true`/`false` and another option provided in the same key? How does that look? Is a `;` used?

Any other things I may have missed asking about?

On 11/02/2016 09:34 PM, Hong Xu wrote:

[William Swanson]

On Fri, Nov 4, 2016 at 10:55 AM, 'Jonathon Marolf' via EditorConfig
<editor...@googlegroups.com> wrote:
> `;` in INI values
>
> There was some discussion on the team on whether `;` or `,` would be better
> separators. `;` seemed a more in-your-face separator than `,` which, since
> this is a weird new thing we are doing, adding multiple options, seemed like
> a good idea. I am not aware of any INI format that chooses one over the
> other, but will happily look into that. Are you aware of any problems in
> other editorconfig parsers with this notation?

INI-style files have historically used semicolons for comments, so the
Visual Studio Code syntax highlighter actually colors the second
option green, like a comment. Using commas here would avoid the issue.

-William Swanson

[Jonathon Marolf]

Good point.  Commas seem preferable then.

[Dmitry Osinovskiy]

Hi Jonathon,

I'm a little bit late to the party, but still my 2 cents after supporting your settings in another tool. I think that specifying a list of values in csharp_new_line_before_open_brace and csharp_space_within_parentheses won't be very convenient for users. Say, I want a new line before open brace for all cases except for lambdas and anonymous methods. I would have to write:

csharp_new_line_before_open_brace = types, methods, properties, indexers, events, event_accessors, control_blocks, anonymous_types, object_collections, array_initializers, local_functions

That looks a little bit cumbersome. IMHO, something like this would be better:

csharp_new_line_before_open_brace = true

csharp_new_line_before_open_brace_lambdas = false

csharp_new_line_before_open_brace_anonymous_methods = false

Also, it would be great to specify default values for settings in documentation. I had to dive in Roslyn sources for that.

Dmitry Osinovskiy

[Jonathon Marolf]

I hear you about needing documentation, I hope to write that soon. So if I'm hearing you correctly you correctly, you want to have an option for each type in addition to the cach-all csharp_new_line_before_open_brace?  Are there other options that you feel this would be beneficial for or just csharp_new_line_before_open_brace?

[Dmitry Osinovskiy]

Yes, an option for each type would be more consistent. I only looked thoroughly at formatting options, and IMHO the following options would be better with this approach (one general option + one option for each type):

1. csharp_new_line_before_open_brace

2. csharp_space_within_parentheses (currently rather inconsistent, as there are separate options for space_between_method_call_parameter_list_parentheses and space_between_method_declaration_parameter_list_parentheses, typeof(...), default(...) and sizeof(...) are treated as method calls without any mention in documentation, and there is no way to change spacing of checked(...))

3. csharp_indent_braces and csharp_indent_block_contents - should be possibly to specify a value for each brace type, like with csharp_new_line_before_open_brace. For example, I have a user request where user doesn't want to have namespace contents indented.

Dmitry

[Jonathon Marolf]

Alright I've opened up this bug to track the work. https://github.com/dotnet/roslyn/issues/16343