Search for a command to run...
My view on why consistent coding standards defined by the creators of the language are not always sunshine and rainbows.
A tinkerer, oft loves to tinker with new tech & languages. Free and Open Source Software enthusiast, creating Apps, Games, CLI stuff, CI/CD, Automation & a lot more. A revert to Islam trying to seek the pleasure of Allah. I love reading psychology, history of nations and mankind & of course docs.
No comments yet. Be the first to comment.
Coding standards are a set of guidelines and best practices that software developers adhere to when writing code. These standards play a crucial role in maintaining code quality, readability, maintainability, and collaboration among developers. However they can either be defined by the language itself, or can be defined by each team / individual for themselves.
Some examples of languages where coding standards are strictly either enforced by the language design or by the creators / foundation are Rust & Go. The reason I really wanted to emphasize on these two is because they not only set standards for the code itself but also the tooling. In the case of rust tools like rustfmt (formatter), cargo (both a build tool and a package manager), rustc (compiler), rustup(installer) are examples where tooling is standardized. Rust goes an extra mile to also ensure stuff like lsp to be standardized. In 2022 the Rust Dev Tools team deprecated RLS in favor of rust-analyzer. It is expected for them to take the community feedback and set the standards for each and everything and rust being rust is a strict language by design, and would usually force you to do things “the correct way” / basically following the standard. When it comes to Go’s language design, there aren’t many ways to achieve the same result as the language was designed to be simple and not be featureful. And when it comes to Go’s tooling it is consistent across the board, they get to standardize the fact that Using Go's module system is now the standard in Go 1.13 among other things. It is common now for newer languages to create or adopt standards for the code and tooling, be it Zig, Odin or any newer language at least to some degree or more. I won’t define each language as I think you get the idea. However this was not always the norm. Here is a quote from Bjarne Stroustrup the creator of C++ himself, when asked about different implementations of C++ i.e clang, gcc, msvc.
When I designed C++ most languages most languages had multiple implementations because if you wanna run on an IBM or run on a Sun or if you wanna run on a Motorolla, those are just many many companies each having their own compilation structure, their own compilers, it was just fairly common that those were many of them and I wrote C front assuming other people would write compilers for C++.
Later on he also talked about different linkers and the positives where this freedom means there was competition and incentive to innovate and optimizations. Here is the link of this talk with Lex Fridman & link for the full talk.
Many devs these days use positive arguments for having strict coding and tooling standards without listing the negatives. Positives such as →
Ease of support - It is easy to support a single standard, which results in less edge cases as it removes stuff like compiler specific bugs. It allows more people to focus on improving a single standard rather than always endorsing competition.
Less developer overhead - When it comes to tooling the user no longer needs to figure out “Should I use pip with the --user flag ?, or maybe use venv or maybe anaconda or pyenv + poetry ?“. This point also makes it very easy for documentation and results in a lot of time saving for both be it the language devs or the devs using the language.
Consistency - This is probably the most common argument as due to having enforced coding styles code bases are generally considered more consistent, which help maintain uniformity across projects. This argument is very much so used against C++ due to the fact that many code bases are legacy and having different standards & addition of features. Consistency results in better code readability which again contributes to time saving and saves you from cephalalgia which results in reduction of medical bills and cost saving.
I would just challenge the readers to take 5 minutes and try to counter each and every point i mentioned above with some positives, this is just to endorse some critical thinking and always questioning and try to play the devil's advocate. And if you are still feel blinding, you might be eating some Primeagens for breakfast. here are some of the counters -
Java for example rallies heavily on third-party tooling. If there was no IntelliJ, or Eclipse or Netbeans back in those days there is always a psychological incentive / expectation from the community to come up with something, same thing with build tools, package management like Gradle and Maven.
Now taking example of Rust before it adopted rust-analyzer and axed RLS. Many people still stayed to RLS due to it being the “official“ standard. As the psychology of the community will always be to stick with the standard. rust-analyzer was better than RLS long before it was the standard. If a better compiler for C++ was to develop today it will get much quicker adoption as community generally expects it. There were discussions on Reddit and various forums where even the creator of RLS was asking people to use rust-analyzer, but it had more downloads and was always the top result on the VS Code Marketplace.
A developer is expected to ask himself/herself “Which x should I use“ (compiler, tool, package manager, coding style etc.). This also incentives a healthy competition and opens a whole new market and innovation.
Less choices / Deal with it - All tho I do agree that if you have set standards they should be of a better high quality than the alternatives (if they exist in the first place) as most of the focus is usually on maintaining and improving that standard. There are cases where this may NOT be the best standard available. rls again is a great example of that. Another great example of this is Node.
I consider JavaScript’s eco system does not fit this article because the default standard is just garbage that many would just look at the alternatives just for that. So community has an incentive to create alternatives for npm like yarn & pnpm and alternatives for node like deno (created by the creator of node) & bun. To a point where the creator of node regrets many design decisions. Usually the default standards for tooling is great and doesn’t give incentive or a reason for community to innovate like cargo for example (Rust community doesn’t expect alternative for cargo because they are happy with it). But JS eco system just does make the community develop stuff to fix its own standard.
When Go introduced generics in 1.18 the community overall was filled with mixed feelings about this. Many were asking for it, many didn’t like the introduction of generics. Now we do see go’s code bases are expected to use generics where it can, that is considered “idiomatic“.
Now rust also keeps introducing features just like C++ but the difference is that in the rust case the definition of idiomatic keeps changing. Your code you wrote 10 years ago may not be idiomatic for today’s standards.
When it comes to C++ it allows versatility and allows companies and dev’s to define their standards. And here I am not talking about C++11, C++17, C++20. But the coding style guides. As an example Google C++ Style guide allows google engineers to follow a single standard and would never be in a hurry to necessarily catchup. Talking about C++ editions, having a lot of legacy means they can’t simply change the standard but they can define one on top of another. Similarly if you look at Java formatters & linters and Python formatters & linters there is no “Right way“. Yes this results in code bases on being less consistent, but also allows freedom & versatility.
Google's C++ style guide for example priorities Abstract classes and compositions over Inheritance. Google also has style guide for Java so does AOSP and so did twitter (they derived most from google).
Like reading code bases, picking and choosing standards can cost time & cause cephalalgia likewise keeping with the standard can also cause the cephalalgia.
Also when people talk about code readability what they usually don’t consider is the use of third-party tools. I am not fighting the code readability argument here but problems do force the community to create. If you try to figure out all the interface implementations, all the abstract classes, all the inheritance with those virtual functions without using the right tool you will end up wasting a lot of your valuable time.
All I wanted to say is that I am NOT saying that strict coding standards are wrong to have, but I am saying they aren’t objectively right either. Many devs these days don’t try to question their own opinions and most don’t want to see things from a subjective eye.
