Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we enforce .NET coding standards to improve productivity

anthonysimmon.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: How we enforce .NET coding standards to improve productivity

#41

Post by xnorswap »

giancarlostoro wrote: post #33

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 tal…

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.

Re: How we enforce .NET coding standards to improve productivity

#42

Post by motorest »

tedggh wrote: post #25

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 hir…

> 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 don't agree. A better fitting comparison would be if a law firm enables spell checkers and proofreads documents to verify they use the law firm's letterhead. Do you waste your time complaining whether the space should go left or right of a bracket?

Re: How we enforce .NET coding standards to improve productivity

#43

Post by maltalex »

kreco wrote: post #22
maltalex wrote: post #4

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…

While msbuild is powerful, I strongly believe it should have been a standard C# language build system instead of a XML-based one. Any non-trivial thing to do is a pain to figure out if the documentation is not extensive enough. I really love C#, but msbuild is one of the weak links to me, almost everything else is a joy to use.

I completely agree that it shouldn’t be XML. Then again, I worked with Gradle in the past, which is based on Groovy syntax plus DSL. And that didn’t feel good either (though I must admit that I knew less about Gradle than I do about msbuild). Perhaps the problem of designing a good build system is harder than it seems.

Re: How we enforce .NET coding standards to improve productivity

#44

Post by appease7727 »

Quarrelsome wrote: post #28
maltalex wrote: post #4

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…

> If you’re working in the .net ecosystem, you need to grok msbuild. Agreed, it makes a huge difference. Sadly Visual Studio made that difficult from the start of .net, given its history with attempting to hide the .csproj files from developers and thus reduce their exposure to it. Its a real shame they decided to build visual studio like that and didn't change it for years.

Huh? You could always access the csproj by right clicking on the project.

Re: How we enforce .NET coding standards to improve productivity

#45

Post by zamalek »

giancarlostoro wrote: post #33

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 tal…

> 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.

Re: How we enforce .NET coding standards to improve productivity

#46

Post by brainzap »

jbjbjbjb wrote: post #36

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.

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.

Re: How we enforce .NET coding standards to improve productivity

#47

Post by jve »

appease7727 wrote: post #44
Quarrelsome wrote: post #28

Earlier quoted context omitted.

> If you’re working in the .net ecosystem, you need to grok msbuild. Agreed, it makes a huge difference. Sadly Visual Studio made that difficult from the start of .net, given its history with attempting to hide the .csproj files from developers and thus reduce their exposure to it. Its a real shame they decided to build visual studio like that and didn't change it for years.

Huh? You could always access the csproj by right clicking on the project.

Not quite. It required you to unload project, then you could right click and edit. And then reload project. And the load could take some time.

Now with sdk style project you just click on the project and the .*proj file comes up and is editable.

Re: How we enforce .NET coding standards to improve productivity

#48

Post by pjob »

kreco wrote: post #22
maltalex wrote: post #4

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…

While msbuild is powerful, I strongly believe it should have been a standard C# language build system instead of a XML-based one. Any non-trivial thing to do is a pain to figure out if the documentation is not extensive enough. I really love C#, but msbuild is one of the weak links to me, almost everything else is a joy to use.

You could check out FAKE. It’s pretty popular in the F# community. While not C#, the terser syntax may be beneficial for a build DSL and you still have access to .NET APIs.

https://fake.build/

Re: How we enforce .NET coding standards to improve productivity

#49

Post by asimmon »

tedggh wrote: post #25

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 hir…

Author here. Thanks for the feedback, I really appreciate.

The code in the screenshot was written poorly on purpose, only for the need of this blog post.

Developers make mistakes at any level of seniority. It's less likely to happen when you reach a certain proficiency in writing C# code, but it's still a possibility. Mistakes can also go through some cracks at review time.

So these are definitely automated guardrails that don't require humans with specific knowledge to enforce them.

Re: How we enforce .NET coding standards to improve productivity

#50

Post by asimmon »

000ooo000 wrote: post #6

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.

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.

Post reply on HN