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

11–20 of 55 posts

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

#11

Post by nathanaldensr »

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

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

#12

Post by tailspin2019 »

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.

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.

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

#13

Post by Kuraj »

tailspin2019 wrote: post #10
[deleted] wrote: post #7

[deleted]

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

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.

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

#14

Post by tailspin2019 »

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…

I agree with you on MsBuild being powerful.

I often really hate certain technologies like MsBuild and use them begrudgingly for years, fighting with the tooling, right up until I decide once and for all to give it enough of my attention to properly learn, and then realise how powerful and useful it actually is!

I went through the same thing with webpack too.

MsBuild is far from perfect though. I often think about trying to find some sort of simple universal build system that I can use across all my projects regardless of the tech stack.

I’ve never really dug much into `make`… Maybe something like that is what I’m yearning for.

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

#16

Post by tailspin2019 »

Kuraj wrote: post #13
tailspin2019 wrote: post #10

Earlier quoted context omitted.

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

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

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

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

#17

Post by jimlawruk »

graboid wrote: post #5

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

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

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

#18

Post by bragh »

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.

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.

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

#19

Post by shortrounddev2 »

tailspin2019 wrote: post #14
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…

I agree with you on MsBuild being powerful. I often really hate certain technologies like MsBuild and use them begrudgingly for years, fighting with the tooling, right up until I decide once and for all to give it enough of my attention to properly learn, and then realise how powerful and useful it actually is! I went through the same thing with webpack too. MsBuild is far from perfect though. I often think about try…

I find this experience a lot with a lot of Microsoft technologies. People bemoan powershell, NT, DirectX, even C# itself, and other Windows APIs but when you get to really learn them you start to miss them on Linux. I sometimes see a meme from beginner programmers lamenting how the world would be better if Windows was POSIX compliant but once you've learned a bit about some of the Windows API calls, POSIX feels absolutely ancient. Some stuff is really dated like Win32 windowing stuff

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

#20

Post by chrisandchris »

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.

> Why not just use dotnet format + .editorconfig

And let the IDE take care of that. Pre-commit Hook and it's all done.

Post reply on HN