How we enforce .NET coding standards to improve productivity • Hacker News Board

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

#51

Post by asimmon » Fri, Aug 08, 2025, 5:06 PM UTC

bragh wrote: post #18

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.

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!

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

#52

Post by Quarrelsome » Fri, Aug 08, 2025, 5:18 PM UTC

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.

as the other person stated, earlier versions of Visual Studio wouldn't let you directly edit the .csproj in the IDE. You were forced to "unload" it first. If you ran an extension to override this behaviour you'd end up with glitches. Its one of the main reasons I moved to Rider given I much prefer to edit the .csproj manually in many cases as opposed to going through the GUI.

There's other little niggles, the Visual Studio gui for example offers a "pre-build" and "post-build" window that's kinda hacky. If you have more than one line in either of the windows the build no longer is able to push the _actual_ error back into the build. So its better to do this with separate target elements (that don't show up in this gui) or just run a pure msbuild file (.proj) to perform these tasks.

Older visual studio was just a bad habit generator/crutch which babied a lot of developers who could have learned better practices (i.e. more familiarity with msbuild) if they had been forced to.

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

#53

Post by WorldMaker » Fri, Aug 08, 2025, 6:22 PM UTC

swader999 wrote: post #26

kreco wrote: post #22

Earlier quoted context omitted.

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 remember using nant back in 2010 or so. Lol those were the days.

I've met teams that strongly prefer Cake [1] and it seems well maintained.

Personally, I think there's too much baby in the MSBuild bathwater unfortunately and too much of the ecosystem is MSBuild to abandon it entirely. That said, I think MSBuild has improved a lot over the last few years. The Sdk-Style .csproj especially has been a great improvement that sanded a lot of rough edges.

[1] https://cakebuild.net/

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

#54

Post by WorldMaker » Fri, Aug 08, 2025, 6:36 PM UTC

rasmuskl wrote: post #24

pestkranker wrote: post #15

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

CSharpier is pretty good for a prettier like feel: https://csharpier.com/

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.

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

#55

Post by tubs » Fri, Aug 08, 2025, 6:52 PM UTC

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.

But you augment it with tools written in c# which is best of both worlds. Builds are defined declaratively and custom actions are defined in code. Not the horrible hybrid of eg ant or cmake.