If you have to keep engineers around who can handle it, it is.
Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.
It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).
No it's not. Lots of languages have broad based understanding of good and bad based on some body, consensus, etc, that does not have mutually incompatible schools of thought that combust wildly when stuck in the same project.
I've never seen a ruby project with a code style guide.
While I've seen python ones (the language closest to C++ in getting randomly hairy different types), the mixups tend to be relatively benign comparatively speaking. Most python projects go with "Look PEP8ish/pythonic".
Objective-C is heavily driven by WWDC presentations and strong recommendations by Apple, so people tend to move to that.
C is all over the map as well, but again, individual complexity of each decision is much lower. You'll have a style guide at a C dev company. "Use lint with these flags and indent with this specifications" is what the best ones have for a majority of their work.
Perl tends to not care, same for php, whereas I think they really should care more.
C#? I've seen style guides, but they're only on about 10-30% projects.
Java: they're usually there.
>"there should be some coding style in a project",
This all comes out to: making all these decisions in a consistant style is MANDATORY for a C++ project. For most others, there are conventions which don't blow things up that make people work generally to a similar enough style. While there may be some codified choices, with C++ in particular, you have TONS of choices, choices that your staff will not all have the same opinions on, choices you'll have to get them onboard with using, onboard with understanding, and thinking in terms of those mechanisms.
That's relatively hard to do. There's so much ramming shit down people's throats in C++ projects that I think it's only worth it in a small small number of cases.
Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.
It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).