Since you specifically mentioned C# : https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
I’d be surprised if there is a serious language that doesn’t come with at least some semi-official style guide. But usually they are not universally followed and everybody just does their own thing.
Just to add, I’d argue dotnet has one of the best sets of guidance on style. It goes beyond just naming and towards how to structure code for easier consumption and consistency. People love to dump on MSFT, but the dotnet platform is superb.
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/
deleted by creator
deleted by creator
I’d be surprised if there is a serious language that doesn’t come with at least some semi-official style guide.
Does JavaScript have one?
Edit: Except google’s style guide
Edit: Except google’s style guide
This legit made me laugh lol, Google’s style guides for their longer standing languages are always dismissed, especially their one for C++
Not sure if they still do it, but Google’s python code is some of the ugliest python I’ve seen and uses 2-space indentation.
What is wrong with Google’s C++ guide?
To summarize the explanations i’ve come across: It’s tailored to Google’s internal teams maintaining tons of legacy C++ code, doesn’t cover exception handling, and generally has outdated advice best suited for the code they developed in that time period. While their style guide is ideal for maintaining consistency with Google’s existing codebase, someone working on a modern C++ project should consider using the language’s more modern features and STL components
Something I’d want to note though, someone developing in C++ for an embedded platform or even working on hardware drivers would probably have very lean and mean code which doesn’t conform to a particular style guide, especially ones advising against use of “unsafe” operations.
Google’s, Mozilla’s and Apple’s style guides are pretty much as official as you’re gonna get here.
The ‘prettier’ formatter is also rather popular and as such its stylistic choices, although that is of course moreso a hammer than a guide.
Is JavaScript a serious language? /s
Joking aside: One of Brendan Eich’s books probably contains something resembling a style guide.
Eslint rules and prettier. I use the AirBnB ruleset as a base close to my personal preferences and then customize to my liking.
I don’t really have to do any manual formatting. I just save to apply the formatting.
edit: javascript
Java walks in, whose stdlib uses different styles in the same file.
Rust has a style guide and comes with a linter. But I don’t think you need to follow it if you don’t want.
Rust, like the majority of modern languages, has an official formatter which everyone should be using. Formatters are good enough nowadays that everyone should be using them.
What other languages have formatter programs?
I’m fond of Go, which comes with its own auto formatter. It eliminates all arguments over style and format.
Beat me to it. There’s plenty to rave about in Go, and that’s definitely one of my favorite things.
Also, it’s refreshing to actually use tab characters and not two spaces or four spaces or whatever.
I absolutely loathe soft tabs. Hard tabs 4lyfe.
I will never forgive this offense
go fmt has been a thing for almost 11 years
deleted by creator
If you’re using visual studio (2022 is current) the idiomatic styling will be mostly correct by default (Ctrl k,e will reformat).
I’ve found it to be less strict than I’d prefer. Things like whether parameters are aligned or indented, whether or not the first one is on its own line, what statements are indented in fluent calls that have blocks, etc.
A lot of other formatters (prettier, anything for python, etc) force something consistent in those cases, whereas it seems like the dotnet formatter prefers to leave things as they were.
I’d love for it to be more opinionated and heavy handed if anyone has suggestions
I’ve never looked into it very deeply, but it uses a styling spec called EditorConfig. Check it out, https://editorconfig.org/
There’s
dotnet formatwhich will format your code. You can configure it with editorconfigFor practical advice, I recommend starting a project with
dotnet new editorconfigwhich covers many of the .NET coding conventions. If you want more strict standards you can use StyleCop, but you will need to configure it a bit to be consistent with the .NET conventions.There are a few coding conventions and style guides for C#:
lots of languages have linters to enforce style. Examples are jslint/eslint phplint, etc…
ESLint will hurt your feelings.
Anyway, I didn’t setup the tooling, and it can be configured to enforce code styles, as it does with each commit. It also enforces rules, but can enforce code style as well.
JavaScript / TypeScript are famously free-form, but a number of styles (and style-enforcing tools) have emerged.
“Prettier” is the most recent. It actually parses your code into an AST and then re-prints it according to its style.
“ESLint” is the most widespread; it is more of a framework into which rules can be plugged.
I use “XO”, which is essentially a custom eslint ruleset with a few other nice things tacked on.
The best part of eslint/xo is the “—fix” command, which can auto-fix most mistakes.
The last part is why you use an IDE.
Several of them will ingest prettier files to build code formatting rules
- https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
- https://www.jetbrains.com/help/webstorm/prettier.html
- https://marketplace.eclipse.org/content/prettier-formatter
IDE support is normally a good way to work out what the wider community is using.
Most languages with “official” formatting guidelines are due to limitations of the compiler/interpreter. Mixing whitespace in Python (or older Fortran) is a great way to error out massively.
For the more modern compiled languages, there is no need. But there still tend to be popular formats from companies like Google
You say this, but C# does have official code style conventions. It’s not about the compiler at all but about ensuring a relatively homogeneous coding style across the ecosystem, so a .NET dev can work on different projects without needing to refamiliarize.
If indentation and newline policies prevent developers from migrating from one project to another then either your developer suck or your language does.
That said, C# is somewhat special in that it is both a language and a corporate flag by Microsoft. Similar to how Google pushes to have their style guides made public so that other projects will adopt them. Which has less to do about making it so that one developer can bounce between projects (because they should be able to anyway) but to instead push Google as the goal everyone aspires to and emulates.
This is about thew new starter cost.
When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc… Often this impacts other members of the team lowering the entire teams productivity.
When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.
So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.
Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.
Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).
Tools and frameworks do indeed take time to come up to speed on. That is onboarding and training
Code formatting should not. If it is taking new developers any meaningful degree of time to adapt to a new style then, again, either your developer or your style sucks. The time it takes to ping HR because they never sent you a document is a much bigger delay than anything else.
And, the very nature of coming up to speed on a code base ensures you figure out any quirks. Because you aren’t making a 10 thousand line pull request on your first day. You are doing something small. So you can get your editor set up to automate most of that and the rest you figure out while going through code review/linting/pre-commit.
So yes, different coding styles will result in minor fluctuations on your “productivity tracking” software. So does having a chair where the reclining lock is in a different position or remembering where the coffee machine is. And if you are at the point where you are optimizing having your developers learn the preferred structure for an if block? You have already won and have the most optimized organization on the planet.
But the reality is that this is the kind of thing that bean counters who use productivity trackers get off on. It allows managers to quantify their employees without ever having to understand what they are doing. And it similarly provides a quantifiable way to say “I improved efficiency by 4% relative to some baseline I cherry picked from the day after a long weekend. Money please!”. Often at the cost of annoying their staff and decreasing the time before people update their linkedins.
Fun story/group therapy time! Couple years back I was on a project where the lead was a REAL moron. Got the job because he was married to the head of a different department and threatened to leave if he didn’t have opportunities for career advancement, etc. Anywho, he insisted we all needed to switch to a “more efficient” coding style (I don’t think it was the google style guide, but one of the popular ones). Took a whole day off of development so we could sit through presentations and do exercises on the benefits of this style while also, obviously, not having time to just set up the pre-commit hooks to automate the migration.
But I was actually in the final days before taking leadership on a different project (which made handing off responsibilities a real pain in the ass but…). And he presented on how amazing the improvements were during one of the project leads meetings. I want to say he measured something like a 30% improvement in SLOC per day which set my BS alarm off massively. Fortunately, as a lead, I now had access to the tools used to collect those metrics. He chose the day where nobody was allowed to code for about 6 hours straight because we were learning about the new system as his baseline. And still only had a 30% gain…
There’s a lot more than indentation and newline policies. The default editorconfig is a few hundred lines. But there’s also no reason not to standardize indentation and newline policies.
Standardizing within a project or even a company is important.
Standardizing across an industry or language is not
Feel free to point out a disadvantage. As a .NET dev I appreciate the semblance of consistency. Different codebases differ enough already, it’s just easier on the eyes when everyone is using the same basic conventions.
Sort of. Python is a lot more ceremonious about its PEPs or whatever, but there are official naming guidelines for .NET in general at least. The rest of it falls more under the general “this and that is considered ‘good’ code, this and that is not”. You could prefer ancient-style C# or heavily functional C#, there’s the SOLID stuff that applies both generally and specifically to OOP, etc
Someone else already mentioned Rust, but to add to it,
rustupinstallsrustfmt(opinionated formatter) andclippy(linter) by default, but you can choose not to run them or even install them.rustfmthas a few configuration options, but is for the most part strict in how it formats code.PEP8 is nice since it sets some common rules across Python projects, but I’m not a fan of some of the decisions they made. The biggest one for me was discouraging defining variables/attributes/etc that use the same name as built-ins. That means no variable named
input, no attr on your data model namedid, etc. Still, since the language doesn’t strictly enforce this, you can easily adjust these rules to meet your project’s needs.I believe
gorequires you to run the bundled formatter to even compile the code, but I could be misremembering.PHP has PSR-1, PSR-2 and now the updated PSR-12: https://www.php-fig.org/psr/psr-12/
I refuse to believe that people use a php style guide. I have yet to open a php file in the course of any job that doesn’t mix tabs and spaces arbitrarily on top of numerous other horrors.
Luckily it’s not often that I have to, so sample size may play in a bit…
For Java, I guess this as official as you can get.
https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
