TL;DR - Coding standards are a shit practice IMO.

What we don't talk about enough among software engineers, is the artistic aspect of the craft of writing code.

For example, consider your client saying this to you.

"Build me a web app where a user will login. They will have a wallet to purchase subscriptions of 3 products of different prices."

Give these two statements to say, 10 devs and see how each of them will come up with their own vision of the problem and how they would implement it in their own ways.

So now you are working on a big team with say 30 people and you have a big project to work on. Different members of the team bring different styles of code to you to review and if, the Team Leader is as incompetent as mine is, they would find it troubling to understand the pull requests.

So what do you do in these scenarios? Implement Coding standards !!! They take away the artistic vision of the devs and tries to force them to follow rules like sheep.

Also the company doesn't give two shits about the code standards cuz, as long as they have working code that makes them money, they wouldn't care how the code is written.

Thoughts ?

Yeah they’re no use, everyone’s code inc. your own is impossible to read a week later. Used to have a really toxic dev in a company who wrote a 30-odd page document that everyone pointedly ignored, would try to call people out on slack for not putting the opening curly brace on a new line and stuff. He never actually wrote anything useful himself.

Coding standards are a good thing - because if you're the maintenance dev years after the fact, you don't want to sift through the eye bleach of an inconsistent code base because each of the previous devs was "artistic".

If you want to do art as dev, use your own hobby projects for that. In a company, you're not paid for art.

@Fast-Nop Agreed, the whole purpose is to make it easier to read each others code.

Yes it does somewhat curtail creativity but if you have multiple people poking around in the same code base all with their own ideas on naming schemas, indentations, code organizations and more you definitely not going to get faster development.

Maybe in the very beginning but very quickly it will become a mess that forces everyone to spend way to much time to understand thing for every minor change.

We need to remember that in any shared project your very likely going to spend many times more time reading code than writing code unless everything is so hard compartmentalized that only one dev ever works on a specific piece of code.

And that requires so much layering that it will snuff out any creativity and the resulting pieces will be only code monkey stuff.

I agree with above 2

It depends on the "How"…

I'll try to split it in 3 categories:
Style
Tooling
Workflows

Style is the easiest. Don't try to come up with an own style. Period. Use best the languages preferred style or a large, supported style - e.g. one a FAANG uses. Reason is pretty darn simple: Compromise is the key. Anything you cook on your own will be a maintenance and discussion hell.

Tooling - very simple. I'm against mandating a specific IDE. But define at least one tool set that ensures a proper code style - best if the *exact* same tooling is used in CI / CD. It's the reference. In case someone comes up with "my thingamabob can't do it" - well, then it's *their* problem. Again, maintenance and support would otherwise waste resources needed elsewhere.

Workflows - well, document things and make sure that there is a workflow.

For the first 2 things, I really don't see a point in involving the team... Discussions are mostly endless with no viable result in the end, mandating is definitely the smartest choice.

Point 3 should be discussed with the teams. Under the premise that noone tries to turn it into a merry go round of insanity.

E.g. the approval of an PR shouldn't be up to debate. I usually try to work out a common netiquette in the workflows. Sounds like kindergarten, but it's one of the things that is really necessary imho cause sometimes teams act like kindergarten kids on chocolate covered espresso beans.

Now we come to the most important part: Keep it short.

The goal of a coding guideline is to ensure that the friction of working together is minimal.

It's neither a lawbook, nor an encyclopedia.

Keep it short, objective and precise.

If discussions are wanted, make sure to explicitly mention that any discussion must have an agenda, a pro -/ con argument and must be mediated. Simple requirements to ensure no one starts a pointless 4 hour plus debate over "i want 2 spaces instead of 4 spaces, cause 2 is my favorite number".

To add to @IntrusionCM, if you do not force a specific IDE please use CLI tools for formatting & linting and not your IDE's (eg black, pylint for Pyrhon; prettier, Eslint for JS): they work cross-platform, -environment and -software.

And choose unopinionated linting rules (ex: I don't agree with the (default off) ESlint JS rule prefer-object-destructuring over Object.assign, both are just as readable)

Instead of domain driven modules like "src/account" and "src/invoice" lets use modules based on each dev: e.g. "src/alice" and "src/bob".

To fix bugs, modules simply override each other based on the org hierarchy: "src/alice/override/bob/...".

Now everyone can be a true code artisan and reinvent the wheel to their hearts content!

Honestly in my opinion e.g. following Microsoft Coding Standard for C# in my case doesn't hinder my creativity.

A macro pattern somewhat does it, but this makes on boarding of people and a discussion where to put something very easy. Also understanding others code is easier for themselfs and others. If done correctly.

For tooling and IDE IMHO everyone should use the same IDE in the same Version. BUT if you use another one and it doesn't break the "standard" we define. You do you.

I do enterprise development and I own a game dev studio. This works on both and all devs feel creative enough, but the code is understandable for everyone.

I really don't think camelCase, PascalCase or other is a creative decision. I try to follow industry standard.

BUT I develop software for 25 years now and I'm used to reading Assembler for different CPUs so I honestly can flex styles easily.For me finding an elegant, performant and/or memory efficient way without microoptimizations is the creative part