6 ms·

How we enforce .NET coding standards to improve productivity

79 points by fratellobigio 1y ago

jbjbjbjb 1y ago
Nuget Audit is an odd one. I usually don’t want all devs to jump on fixing the latest vulnerability right away. We have a separate pipeline for resolving those issues.
- pc86 1y ago
  I've actually changed my mind on this, if you're working in a project that's doesn't have a ton of early-lifecycle v0 packages. If there is a lot of quick churn in your dependencies, yeah you want to devote dedicated engineering resources to keeping these up-to-date and regression testing things. If everything is pretty stable, it's nice to have each developer share the work with keeping things up-to-date and functional. Broad automated test coverage makes this a lot easier of course.
- brainzap 1y ago
  Thats ok. The team can decide what process they do. We do, update packages every 3 months. Criticals are reported by a pipeline and are fixed same week.
reverseblade2 1y ago
Title should be C# not .Net
- algorithmsRcool 1y ago
  I'm not sure i understand your comment, .editorconfig works just fine for VB files as well as F#
  - nickpeterson 1y ago
    You could almost think of F# is an extremely strict set of conventions for C# … ;)
    - pc86 1y ago
      You could, but you'd be wrong.
maltalex 1y ago
If you’re working in the .net ecosystem, you need to grok msbuild. Is not exactly painless or elegant, but is incredibly powerful. Creating a nuget package that applies settings and configuration files to consuming projects is the tip of a very deep iceberg. I’m the author and owner of a similar code style/code quality package in a fairly large company and went through a very similar process, culminating with writing our own Roslyn-based analyzers to enforce various internal practices to supplant the customized configuration of the Microsoft provided analyzers. Also, we discovered that different projects need different level of analysis. We’re less strict with e.g test projects than core infrastructure. But all projects need to have the same formatting and style. That too can be easily done with one nuget using msbuild.
- johnfonesca 1y ago
  >But all projects need to have the same formatting and style.That too can be easily done with one nuget using msbuild. That's like using a car for "traveling" 3 meters. Why not just use dotnet format + .editorconfig , they were created just for this purpose.
  - nathanaldensr 1y ago
    It's a combination of practices, some at develop-time and some at CI-time. The general goal is to have code as clean and standardized as possible as early as possible, especially on larger teams where human enforcement doesn't scale as much.
  - chrisandchris 1y ago
    > Why not just use dotnet format + .editorconfig And let the IDE take care of that. Pre-commit Hook and it's all done.
  - maltalex 1y ago
    It doesn’t scale as well across a large org. We have hundreds of repos, thousands of projects. It is hard to ensure consistency at scale with a local .editorconfig in every repo. Also, with a nuget I can do a lot more than what editorconfig allows. Our package includes custom analyzers, custom spell check dictionaries, and multiple analysis packages (i.e not just the Microsoft provided analyzers). We support different levels of analysis for different projects based on project type (with automatic type detection). Not to mention that coding practices evolve with time, tastes, and new language features. And those changes also need to be consistently applied. With a package, all we need to do to apply all of the above consistently across the whole company is to bump a single version.
graboid 1y ago
At work, we use the .editorconfig of the .NET runtime, with slight modifications: https://github.com/dotnet/runtime/blob/main/.editorconfig https://github.com/dotnet/runtime/blob/main/.editorconfig
- jimlawruk 1y ago
  This appears to be the OP / Workleap's editor config. https://github.com/workleap/wl-dotnet-codingstandards/blob/main/.editorconfig https://github.com/workleap/wl-dotnet-codingstandards/blob/m...
000ooo000 1y ago
Pretty long article with not a great deal of substance beyond what is mentioned early on. Would be interested to know how much input teams had in the rule configuration before this was foisted on them.
- tailspin2019 1y ago
  Plenty of substance in there for me. I’ve been building with dotnet since it existed and still learned a couple of new techniques/ideas from this article.
- bragh 1y ago
  There is quite useful content in there, but the writing style makes it very annoying to read, it feels as if the original text went through some kind of LLM filter and made it corporately soulless, as seems to be the good practice now.
  - asimmon 1y ago
    Author again here. I'm sorry to hear this. I wrote the whole thing in a mix of French and English (mostly English), and yes, it went through an LLM, but only to correct mistakes and translate French parts. I'm limited in my ability to write beautiful/delightful blog posts as English is not my main language. Using an LLM wasn't about rewriting the whole thing, many sentences were left as before, so the style is definitely mine. It's okay if you don't like it, I'm trying to get better at it!
- asimmon 1y ago
  Author here. Even though we have different teams and products/services, there's still a baseline of "historical" code style and rule configuration at our company. Also, I personally explored the various codebases and reached out to several developers to get some feedback throughout the process. The whole thing did not come out as a surprise for most of us. Even so, for those who were not aware of it, the benefits - as I captured screenshots of improvements highlighted from the warnings in their codebases after installing an alpha version of the package - were obvious. Adoption was quite smooth and easy at first. Definitely not pushed onto teams for several weeks/months, until enough repos were onboarded and we had enough feedback that it would be beneficial for the whole company to use this.
deleted 1y ago
[deleted]
- tailspin2019 1y ago
  The article does mention they only turn on “TreatWarningAsErrors” in production builds. It’s definitely a tough balance to strike. I go back and forth on this myself. Maybe the happy medium is to have everything strictly enforced in CI, relatively relaxed settings during normal dev loop builds and then perhaps a pre-commit build configuration that forces/reminds you to do one production build before pushing… (which if you miss, just means you may end up with a failed CI build to fix…)
  - Kuraj 1y ago
    The original comment was about whether these things should be treated as errors during the local development process, or during CI for greenfield projects. I deleted it after realizing that the article actually does address this. But I'm still relieved that I'm not the only one with the dillema. > which if you miss, just means you may end up with a failed CI build to fix… Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows (maybe after making that mistake once or twice :-)) that they can't just be ignored because they will fail down the road.
    - tailspin2019 1y ago
      > Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows that they can't just be ignored because they will fail down the road. Yeah I agree. This has got me thinking a bit more actually about how to optimise build configurations much more deliberately. Dev loop builds vs “normal” (local) builds vs production builds. I got into the habit of turning on TreatWarningsAsErrors in greenfield .NET projects, trying to be a disciplined developer… But often these warnings can be a distraction during fast iterations… I think I may change my policy…
pestkranker 1y ago
Is there a 'prettier' equivalent for code formatting? In my opinion, it's the only thing missing for a truly scalable codebase.
- leosanchez 1y ago
  dotnet format[0] with .editorconfig should do the job. [0]: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-format https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-f...
- rasmuskl 1y ago
  CSharpier is pretty good for a prettier like feel: https://csharpier.com/ https://csharpier.com/
  - WorldMaker 1y ago
    I currently somewhat wish CSharpier could also install (or modify, if we are wishing for ponies) an .editorconfig that matches its settings enough that someone with a habit of existing `dotnet format` or who hasn't yet installed CSharpier's own IDE extensions doesn't have a "bad time" or accidentally create a lot of commit churn. Prettier was relatively easy to adopt because most styles at the time were just eslint configurations and auto-formatters were scarce before Prettier. .NET has a long history of auto-formatters and most of them speak .editorconfig, so some interop would be handy, even if the goal isn't "perfect" interop. Just enough to build a pit of success for someone's first or second PR in a project before they get to that part of the Readme that says "install this thing in VS or Rider" or actually start to pay attention to the Workspace-recommended extensions in VS Code.
tedggh 1y ago
This is a good article and I appreciate the author sharing his ideas. But that screenshot showing an example of poorly written code. Man if someone in your team is writing code like that you have much more serious problems. I understand the need for guardrails and standards, but when you go through the right process of hiring someone and giving an offer this should not happen. This is the equivalent of a law firm hiring a lawyer then adding a tool that checks their work when drafting documents making sure they don’t make mistakes. I’m not talking about complex compliance issues but fundamental knowledge a lawyer should have. The case can be made this is for junior developers, and I agree it can be useful, but there’s usually a path for junior developers that involves 1:1 mentorship before they start pushing critical code. We do have standards and guidelines in my team, but most of them are nice-to-haves. We assume we are all professionals and trust each other’s work even when many times we disagree on design and coding style. Our effort and enforcement is testing, accountability and good documentation. We nudge for readable code. We have a guy that loves Regex and we let him use it if well documented.
- Quarrelsome 1y ago
  isn't it[0] intentionally bad, so as to highlight the things .editorconfig might suggest to improve it? [0] https://anthonysimmon.com/workleap-dotnet-coding-standards/warnings_hu_2e5a93028011a8e2.png https://anthonysimmon.com/workleap-dotnet-coding-standards/w...
- hk1337 1y ago
  I remember seeing at one job, to share a “token” that was in a byte array, they iterated the byte array and concatenated the values. It was supposed to be an internal “auth tool”/“sso” but was unusable in the php app I was trying to use it with because it couldn’t (or at least I wasn’t sure how to) convert the byte array back. I ended up writing a small Java console app to convert it for me.
- gwbas1c 1y ago
  > But that screenshot showing an example of poorly written code. That screenshot looks like it was specifically written for the blog entry. (The project is called ConsoleApp1.) I suspect the author didn't want to show their employer's proprietary code on their blog, and probably wanted to make a concise screenshot with multiple errors. (Otherwise, they might have people who don't have a programming background occasionally writing non-production tools as part of a non-software-engineering job. This is quite common in many workplaces.)
bob1029 1y ago
It's probably a bit overkill for most shops, but you can actually write your own code fixes if you've got some common pattern: https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/tutorials/how-to-write-csharp-analyzer-code-fix#write-the-code-fix https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/t... These suggestions being immediately executable can dramatically improve compliance. I find myself taking things like range operator syntax even though I don't really prefer it simply because the tool does the conversion automatically for me.
giancarlostoro 1y ago
I used to recommend editorconfig and better tools for .NET nearly ten years ago. I never seem to get hired anywhere that appreciates better tooling and sane processes. All to the impediment of everyones productivity no less. Just kind of giving up at this point. They are perfectly fine with waiting an extra day for every developer to finish simple tasks that better tooling could have helped with and I am not even talking about AI. Better database tools, better code refactoring that catches bugs before they happen. Lots of simple things.
- xnorswap 1y ago
  The trick isn't to convince, it's to just do. How I approached it for an org with 300 projects and 10k+ failures after adding the analyzer. 1. Add .editorconfig and analyzer anyway 2. Ignore all the failing analyzer rules in .editorconfig That's your baseline. Even if you have to ignore 80% of rules, that's still 20% of rules now being enforced going forward, which puts a stake in the ground. Even if the .editorconfig doesn't enforce much yet, it allows incremental progress. Crucially, your build still passes, it can get through code review, and it doesn't need to change a huge amount of existing code, so you won't cause massive merge issues or git-blame headaches. 3. Over time, take a rule from the ignored list, clean up the code base to meet that rule, then un-ignore. How often you do such "weeding", and whether you can get any help with it, is up to you, but it's no longer a blocker, it's not on any critical path, it's just an easy way to pay down some technical debt. Eventually you might be able to convince your team of the value. When they have fewer merge conflicts because there's fewer "random" whitespace changes. When they save time and get to address and fix a problem in private rather than getting to PR, etc. Generally it's easier to ask forgiveness than permission. But you've got to also minimise the disruption when you introduce tooling. Make it easy for teammates to pick up the tooling, not a problem they now have to deal with.
- zamalek 1y ago
  > I used to recommend editorconfig and better tools for .NET nearly ten years ago. Languages/tools that are not configurable and just dish out the will of the maintainers are objectively superior. This is all a weird type of mandatory bikeshedding; you need to do it, but it doesn't add anything of value to the product. Everyone is going to have a distinct opinion because they earned their programming chops at some shop that did things in some weird way. .editorconfig is an anti-solution.
gwbas1c 1y ago
I can vouche for .editorconfig. I set it up at my current job (although not to the degree in this article.) The big problem we had was an old codebase, with a very inconsistent style, that had a lot of code written by junior developers and non-developers. This resulted in a situation where, every time I had to work in an area of the code I hadn't seen before, the style was so different I had to refactor it just to understand it. .editorconfig (with dotnet-format) fixed this.
jasonthorsness 1y ago
Haven’t done much in C# since Claude Code has been available but I’ve found strict linting and style rules are very helpful for such agents when writing Go. I used to run a fairly strict and customized config with StyleCop etc; I wonder if something maybe more standardized like this will be more effective.

79 points by fratellobigio 1y ago

Nuget Audit is an odd one. I usually don’t want all devs to jump on fixing the latest vulnerability right away. We have a separate pipeline for resolving those issues.

pc86 1y ago
I've actually changed my mind on this, if you're working in a project that's doesn't have a ton of early-lifecycle v0 packages. If there is a lot of quick churn in your dependencies, yeah you want to devote dedicated engineering resources to keeping these up-to-date and regression testing things. If everything is pretty stable, it's nice to have each developer share the work with keeping things up-to-date and functional. Broad automated test coverage makes this a lot easier of course.
brainzap 1y ago
Thats ok. The team can decide what process they do. We do, update packages every 3 months. Criticals are reported by a pipeline and are fixed same week.

reverseblade2 1y ago

Title should be C# not .Net

algorithmsRcool 1y ago
I'm not sure i understand your comment, .editorconfig works just fine for VB files as well as F#
- nickpeterson 1y ago
  You could almost think of F# is an extremely strict set of conventions for C# … ;)
  - pc86 1y ago
    You could, but you'd be wrong.

maltalex 1y ago

If you’re working in the .net ecosystem, you need to grok msbuild. Is not exactly painless or elegant, but is incredibly powerful. Creating a nuget package that applies settings and configuration files to consuming projects is the tip of a very deep iceberg. I’m the author and owner of a similar code style/code quality package in a fairly large company and went through a very similar process, culminating with writing our own Roslyn-based analyzers to enforce various internal practices to supplant the customized configuration of the Microsoft provided analyzers. Also, we discovered that different projects need different level of analysis. We’re less strict with e.g test projects than core infrastructure. But all projects need to have the same formatting and style. That too can be easily done with one nuget using msbuild.

johnfonesca 1y ago
>But all projects need to have the same formatting and style.That too can be easily done with one nuget using msbuild. That's like using a car for "traveling" 3 meters. Why not just use dotnet format + .editorconfig , they were created just for this purpose.
- nathanaldensr 1y ago
  It's a combination of practices, some at develop-time and some at CI-time. The general goal is to have code as clean and standardized as possible as early as possible, especially on larger teams where human enforcement doesn't scale as much.
- chrisandchris 1y ago
  > Why not just use dotnet format + .editorconfig And let the IDE take care of that. Pre-commit Hook and it's all done.
- maltalex 1y ago
  It doesn’t scale as well across a large org. We have hundreds of repos, thousands of projects. It is hard to ensure consistency at scale with a local .editorconfig in every repo. Also, with a nuget I can do a lot more than what editorconfig allows. Our package includes custom analyzers, custom spell check dictionaries, and multiple analysis packages (i.e not just the Microsoft provided analyzers). We support different levels of analysis for different projects based on project type (with automatic type detection). Not to mention that coding practices evolve with time, tastes, and new language features. And those changes also need to be consistently applied. With a package, all we need to do to apply all of the above consistently across the whole company is to bump a single version.

graboid 1y ago

At work, we use the .editorconfig of the .NET runtime, with slight modifications: https://github.com/dotnet/runtime/blob/main/.editorconfig https://github.com/dotnet/runtime/blob/main/.editorconfig

jimlawruk 1y ago
This appears to be the OP / Workleap's editor config. https://github.com/workleap/wl-dotnet-codingstandards/blob/main/.editorconfig https://github.com/workleap/wl-dotnet-codingstandards/blob/m...

000ooo000 1y ago

Pretty long article with not a great deal of substance beyond what is mentioned early on. Would be interested to know how much input teams had in the rule configuration before this was foisted on them.

tailspin2019 1y ago
Plenty of substance in there for me. I’ve been building with dotnet since it existed and still learned a couple of new techniques/ideas from this article.
bragh 1y ago
There is quite useful content in there, but the writing style makes it very annoying to read, it feels as if the original text went through some kind of LLM filter and made it corporately soulless, as seems to be the good practice now.
- asimmon 1y ago
  Author again here. I'm sorry to hear this. I wrote the whole thing in a mix of French and English (mostly English), and yes, it went through an LLM, but only to correct mistakes and translate French parts. I'm limited in my ability to write beautiful/delightful blog posts as English is not my main language. Using an LLM wasn't about rewriting the whole thing, many sentences were left as before, so the style is definitely mine. It's okay if you don't like it, I'm trying to get better at it!
asimmon 1y ago
Author here. Even though we have different teams and products/services, there's still a baseline of "historical" code style and rule configuration at our company. Also, I personally explored the various codebases and reached out to several developers to get some feedback throughout the process. The whole thing did not come out as a surprise for most of us. Even so, for those who were not aware of it, the benefits - as I captured screenshots of improvements highlighted from the warnings in their codebases after installing an alpha version of the package - were obvious. Adoption was quite smooth and easy at first. Definitely not pushed onto teams for several weeks/months, until enough repos were onboarded and we had enough feedback that it would be beneficial for the whole company to use this.

deleted 1y ago

[deleted]

tailspin2019 1y ago
The article does mention they only turn on “TreatWarningAsErrors” in production builds. It’s definitely a tough balance to strike. I go back and forth on this myself. Maybe the happy medium is to have everything strictly enforced in CI, relatively relaxed settings during normal dev loop builds and then perhaps a pre-commit build configuration that forces/reminds you to do one production build before pushing… (which if you miss, just means you may end up with a failed CI build to fix…)
- Kuraj 1y ago
  The original comment was about whether these things should be treated as errors during the local development process, or during CI for greenfield projects. I deleted it after realizing that the article actually does address this. But I'm still relieved that I'm not the only one with the dillema. > which if you miss, just means you may end up with a failed CI build to fix… Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows (maybe after making that mistake once or twice :-)) that they can't just be ignored because they will fail down the road.
  - tailspin2019 1y ago
    > Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows that they can't just be ignored because they will fail down the road. Yeah I agree. This has got me thinking a bit more actually about how to optimise build configurations much more deliberately. Dev loop builds vs “normal” (local) builds vs production builds. I got into the habit of turning on TreatWarningsAsErrors in greenfield .NET projects, trying to be a disciplined developer… But often these warnings can be a distraction during fast iterations… I think I may change my policy…

pestkranker 1y ago

Is there a 'prettier' equivalent for code formatting? In my opinion, it's the only thing missing for a truly scalable codebase.

leosanchez 1y ago
dotnet format[0] with .editorconfig should do the job. [0]: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-format https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-f...
rasmuskl 1y ago
CSharpier is pretty good for a prettier like feel: https://csharpier.com/ https://csharpier.com/
- WorldMaker 1y ago
  I currently somewhat wish CSharpier could also install (or modify, if we are wishing for ponies) an .editorconfig that matches its settings enough that someone with a habit of existing `dotnet format` or who hasn't yet installed CSharpier's own IDE extensions doesn't have a "bad time" or accidentally create a lot of commit churn. Prettier was relatively easy to adopt because most styles at the time were just eslint configurations and auto-formatters were scarce before Prettier. .NET has a long history of auto-formatters and most of them speak .editorconfig, so some interop would be handy, even if the goal isn't "perfect" interop. Just enough to build a pit of success for someone's first or second PR in a project before they get to that part of the Readme that says "install this thing in VS or Rider" or actually start to pay attention to the Workspace-recommended extensions in VS Code.

tedggh 1y ago

This is a good article and I appreciate the author sharing his ideas. But that screenshot showing an example of poorly written code. Man if someone in your team is writing code like that you have much more serious problems. I understand the need for guardrails and standards, but when you go through the right process of hiring someone and giving an offer this should not happen. This is the equivalent of a law firm hiring a lawyer then adding a tool that checks their work when drafting documents making sure they don’t make mistakes. I’m not talking about complex compliance issues but fundamental knowledge a lawyer should have. The case can be made this is for junior developers, and I agree it can be useful, but there’s usually a path for junior developers that involves 1:1 mentorship before they start pushing critical code. We do have standards and guidelines in my team, but most of them are nice-to-haves. We assume we are all professionals and trust each other’s work even when many times we disagree on design and coding style. Our effort and enforcement is testing, accountability and good documentation. We nudge for readable code. We have a guy that loves Regex and we let him use it if well documented.

Quarrelsome 1y ago
isn't it[0] intentionally bad, so as to highlight the things .editorconfig might suggest to improve it? [0] https://anthonysimmon.com/workleap-dotnet-coding-standards/warnings_hu_2e5a93028011a8e2.png https://anthonysimmon.com/workleap-dotnet-coding-standards/w...
hk1337 1y ago
I remember seeing at one job, to share a “token” that was in a byte array, they iterated the byte array and concatenated the values. It was supposed to be an internal “auth tool”/“sso” but was unusable in the php app I was trying to use it with because it couldn’t (or at least I wasn’t sure how to) convert the byte array back. I ended up writing a small Java console app to convert it for me.
gwbas1c 1y ago
> But that screenshot showing an example of poorly written code. That screenshot looks like it was specifically written for the blog entry. (The project is called ConsoleApp1.) I suspect the author didn't want to show their employer's proprietary code on their blog, and probably wanted to make a concise screenshot with multiple errors. (Otherwise, they might have people who don't have a programming background occasionally writing non-production tools as part of a non-software-engineering job. This is quite common in many workplaces.)

bob1029 1y ago

It's probably a bit overkill for most shops, but you can actually write your own code fixes if you've got some common pattern: https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/tutorials/how-to-write-csharp-analyzer-code-fix#write-the-code-fix https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/t... These suggestions being immediately executable can dramatically improve compliance. I find myself taking things like range operator syntax even though I don't really prefer it simply because the tool does the conversion automatically for me.

giancarlostoro 1y ago

I used to recommend editorconfig and better tools for .NET nearly ten years ago. I never seem to get hired anywhere that appreciates better tooling and sane processes. All to the impediment of everyones productivity no less. Just kind of giving up at this point. They are perfectly fine with waiting an extra day for every developer to finish simple tasks that better tooling could have helped with and I am not even talking about AI. Better database tools, better code refactoring that catches bugs before they happen. Lots of simple things.

xnorswap 1y ago
The trick isn't to convince, it's to just do. How I approached it for an org with 300 projects and 10k+ failures after adding the analyzer. 1. Add .editorconfig and analyzer anyway 2. Ignore all the failing analyzer rules in .editorconfig That's your baseline. Even if you have to ignore 80% of rules, that's still 20% of rules now being enforced going forward, which puts a stake in the ground. Even if the .editorconfig doesn't enforce much yet, it allows incremental progress. Crucially, your build still passes, it can get through code review, and it doesn't need to change a huge amount of existing code, so you won't cause massive merge issues or git-blame headaches. 3. Over time, take a rule from the ignored list, clean up the code base to meet that rule, then un-ignore. How often you do such "weeding", and whether you can get any help with it, is up to you, but it's no longer a blocker, it's not on any critical path, it's just an easy way to pay down some technical debt. Eventually you might be able to convince your team of the value. When they have fewer merge conflicts because there's fewer "random" whitespace changes. When they save time and get to address and fix a problem in private rather than getting to PR, etc. Generally it's easier to ask forgiveness than permission. But you've got to also minimise the disruption when you introduce tooling. Make it easy for teammates to pick up the tooling, not a problem they now have to deal with.
zamalek 1y ago
> I used to recommend editorconfig and better tools for .NET nearly ten years ago. Languages/tools that are not configurable and just dish out the will of the maintainers are objectively superior. This is all a weird type of mandatory bikeshedding; you need to do it, but it doesn't add anything of value to the product. Everyone is going to have a distinct opinion because they earned their programming chops at some shop that did things in some weird way. .editorconfig is an anti-solution.

gwbas1c 1y ago

I can vouche for .editorconfig. I set it up at my current job (although not to the degree in this article.) The big problem we had was an old codebase, with a very inconsistent style, that had a lot of code written by junior developers and non-developers. This resulted in a situation where, every time I had to work in an area of the code I hadn't seen before, the style was so different I had to refactor it just to understand it. .editorconfig (with dotnet-format) fixed this.

jasonthorsness 1y ago

Haven’t done much in C# since Claude Code has been available but I’ve found strict linting and style rules are very helpful for such agents when writing Go. I used to run a fairly strict and customized config with StyleCop etc; I wonder if something maybe more standardized like this will be more effective.