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

31–40 of 55 posts

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

#31

Post by gwbas1c »

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…

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

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

#32

Post by maltalex »

johnfonesca wrote: post #9
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…

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

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.

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

#33

Post by giancarlostoro »

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.

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

#34

Post by gwbas1c »

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.

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

#35

Post by xnorswap »

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…

I couldn't disagree more.

How do you expect junior programmers to become senior ones without help? Having automated guard-rails saves a large amount of your senior devs time by avoiding them having to pick such things up in code review, and you'll find the junior programmers absorb the rules in time and learn.

Several of the examples are nitpicking naming, this is exactly what should be automated. It's not like even experienced people won't accidentally use camelCase instead of PascalCase sometimes, or maybe accidentally snake_case something especially if they're having to mix C# back-end with JS frontend with different naming conventions.

Picking it up immediately in the IDE is a massive time-save for everyone.

The "There is an Async alternative" is a great roslyn rule. Depending on the API, some of those async overloads might not even have existed in the past, e.g. JSON serialisation, so having something to prompt "Hey, there's a better way to do this!" is actually magical.

Unused local variables are less likely, but they still happen, especially if a branch later has been removed. Having it become a compiler error helps force the dev to clean up as they go.

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

#37

Post by jasonthorsness »

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.

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

#38

Post by xnorswap »

johnfonesca wrote: post #9
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…

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

They're talking about how to sync the .editorconfig if projects are not in a mono-repo.

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

#39

Post by pc86 »

nickpeterson wrote: post #8
algorithmsRcool wrote: post #3

Earlier quoted context omitted.

I'm not sure i understand your comment, .editorconfig works just fine for VB files as well as F#

You could almost think of F# is an extremely strict set of conventions for C# … ;)

You could, but you'd be wrong.

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

#40

Post by pc86 »

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.

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.

Post reply on HN