In short: I no longer need it, and I've lost interest in maintaining it.
When I originally built this set of analyzers, I worked as an application developer. At the companies I worked for, it was common practice to bring in external developers for a few months to help the internal team build new features, depending on demand. With developers coming and going often, we always had conversations about best practices and code style. Standardizing on CSharpGuidelines with the accompanying analyzers helped at the time.
Nowadays, I work at a big tech company, building developer tools and libraries. Similar to teams within Microsoft (runtime, Roslyn, EF Core, VS), it's common practice to have small, highly specialized teams of developers who stay for decades. As a result, we don't need a document that we can point new team members to. Whenever code style questions come up (usually due to new language features), we debate, make a decision (and, when possible, automate its enforcement), then move on. The kind of code we write is also pretty different. We're not interested in rules about domain-driven design or union architectures. We all know about design patterns, proper error handling, asynchrony and multi-threading, etc. Our challenges are performance and scalability, lock-free threading, stable public APIs for third-party extensibility, cross-platform support, and providing good API documentation and runnable samples.
By now, the landscape of analyzers, code formatters and related tools has changed a lot. Existing tools have improved, and new ones have emerged. Generative AI is gaining ground, which is pretty capable of adhering to the existing style in a codebase.
I've prototyped upgrading the analyzers to the latest version of Roslyn and assessed what it would take to add support for all the new C# language features since I built them. My conclusion is that this is a lot of work. Using the Roslyn APIs effectively is still barely documented, and measuring their performance impact remains challenging because it depends heavily on the codebase being scanned. I've concluded that applying Clean Code practices to this project, as I initially did, is counterproductive. For example, the analyzers that ship with Roslyn are supposed to help analyzer developers avoid common pitfalls, but they only trigger in the analyzer class itself. So refactoring into separate types causes them to no longer show up. Another concern with writing analyzers is keeping allocations to a minimum (they potentially execute on every key press), which makes instantiating many single-responsibility classes an anti-pattern.
While I still believe CSharpGuidelines can be helpful to application developer teams, I'm not the right person to judge that anymore. The guidelines reflect Dennis' ongoing experience with what works best and what matters among the teams he works with. It is only natural that such guidance evolves over time, adding new rules, removing existing ones and adapting existing ones. I can't combine that very well with an analyzer project, where stability is key: existing codebases contain rule suppressions and adding new rules or changing existing ones are breaking changes.
Teams that still care about the analyzers in this project are free to fork them and adapt accordingly. I wish you all the best.
In short: I no longer need it, and I've lost interest in maintaining it.
When I originally built this set of analyzers, I worked as an application developer. At the companies I worked for, it was common practice to bring in external developers for a few months to help the internal team build new features, depending on demand. With developers coming and going often, we always had conversations about best practices and code style. Standardizing on CSharpGuidelines with the accompanying analyzers helped at the time.
Nowadays, I work at a big tech company, building developer tools and libraries. Similar to teams within Microsoft (runtime, Roslyn, EF Core, VS), it's common practice to have small, highly specialized teams of developers who stay for decades. As a result, we don't need a document that we can point new team members to. Whenever code style questions come up (usually due to new language features), we debate, make a decision (and, when possible, automate its enforcement), then move on. The kind of code we write is also pretty different. We're not interested in rules about domain-driven design or union architectures. We all know about design patterns, proper error handling, asynchrony and multi-threading, etc. Our challenges are performance and scalability, lock-free threading, stable public APIs for third-party extensibility, cross-platform support, and providing good API documentation and runnable samples.
By now, the landscape of analyzers, code formatters and related tools has changed a lot. Existing tools have improved, and new ones have emerged. Generative AI is gaining ground, which is pretty capable of adhering to the existing style in a codebase.
I've prototyped upgrading the analyzers to the latest version of Roslyn and assessed what it would take to add support for all the new C# language features since I built them. My conclusion is that this is a lot of work. Using the Roslyn APIs effectively is still barely documented, and measuring their performance impact remains challenging because it depends heavily on the codebase being scanned. I've concluded that applying Clean Code practices to this project, as I initially did, is counterproductive. For example, the analyzers that ship with Roslyn are supposed to help analyzer developers avoid common pitfalls, but they only trigger in the analyzer class itself. So refactoring into separate types causes them to no longer show up. Another concern with writing analyzers is keeping allocations to a minimum (they potentially execute on every key press), which makes instantiating many single-responsibility classes an anti-pattern.
While I still believe CSharpGuidelines can be helpful to application developer teams, I'm not the right person to judge that anymore. The guidelines reflect Dennis' ongoing experience with what works best and what matters among the teams he works with. It is only natural that such guidance evolves over time, adding new rules, removing existing ones and adapting existing ones. I can't combine that very well with an analyzer project, where stability is key: existing codebases contain rule suppressions and adding new rules or changing existing ones are breaking changes.
Teams that still care about the analyzers in this project are free to fork them and adapt accordingly. I wish you all the best.