[tedggh]

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 hiring a lawyer then adding a tool that checks their work when drafting documents making sure they don’t make mistakes. I’m not talking about complex compliance issues but fundamental knowledge a lawyer should have. The case can be made this is for junior developers, and I agree it can be useful, but there’s usually a path for junior developers that involves 1:1 mentorship before they start pushing critical code. We do have standards and guidelines in my team, but most of them are nice-to-haves. We assume we are all professionals and trust each other’s work even when many times we disagree on design and coding style. Our effort and enforcement is testing, accountability and good documentation. We nudge for readable code. We have a guy that loves Regex and we let him use it if well documented.

[gwbas1c]

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

[hk1337]

I remember seeing at one job, to share a “token” that was in a byte array, they iterated the byte array and concatenated the values. It was supposed to be an internal “auth tool”/“sso” but was unusable in the php app I was trying to use it with because it couldn’t (or at least I wasn’t sure how to) convert the byte array back. I ended up writing a small Java console app to convert it for me.

[Quarrelsome]

isn't it[0] intentionally bad, so as to highlight the things .editorconfig might suggest to improve it?

[0] https://anthonysimmon.com/workleap-dotnet-coding-standards/w...

[asimmon]

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.

[motorest]

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

[xnorswap]

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.