Set csharp_indent_case_contents_when_block to false

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[tannergooding]

The VS default and therefore our default is csharp_indent_case_contents_when_block = true which is that way for historical reasons:

// csharp_indent_case_contents_when_block = truecase0:{Console.WriteLine("Hello");break;}// csharp_indent_case_contents_when_block = falsecase0:{Console.WriteLine("Hello");break;}

But this default is inconsistent with the indentation used for block expressions given if, else, for, foreach, do, while, switch itself, etc. So this makes case consistent with all other scenarios, makes the code more readable, and avoids devs needing to fight formatting with VS.

[tannergooding]

CC. @stephentoub

[sharwell]

The VS default and therefore our default

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

[tannergooding]

This is a bit misleading. The previous .editorconfig included a definition for this item, so the VS default would never be used. The VS default is also never used if EnforceCodeStyleInBuild is set to true (we fall back to the Roslyn option default if .editorconfig doesn't define it).

I think you misunderstood the statement.

The statement was that we had our .editorconfig explicitly encode the defaults that exist provided no other overrides exist. That is, the Roslyn default (if no setting overrides it) matches the historical VS default (assuming default settings and no user customization of the behavior) and our .editorconfig explicitly encoded that to ensure that any user preferences would not be picked up, as is the recommended way to set up an .editorconfig file.

That historical default is largely undesirable, but one that we can't change due to backwards compatibility concerns across the entire .NET ecosystem.

Are there plans to make a pass and ensure existing code is normalized to the new form? Changing an option without normalizing the code can produce a long tail of churn in pull requests.

We typically don't do that.

We have millions of lines of code that have been built up over 20 years and it's already in a state where not all of it follows the code style conventions. We instead simply get new code in the correct format and sometimes fixup the code in existing files when we're doing larger refactorings.

This is a place where a lot of our code, especially new code, is already following the format covered by the change in the PR and it's simply helping to ensure that we aren't needing to fight the IDE when working in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.