[hi_herbert]

Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every language and are very useful. Now I agree about two things: 1) the stream api is a bit (not that much though) verbose, which significantly contrast with Kotlin. Although e.g .toList() helps 2) yes develpers especially junior ones are eager to abuse functors in an unreadable mess. When there is complexity using loops is usually more readable. Streams however are very fit for regular ETL that represents ~70% of code for most simple apps. The pinnacle of complexity would be e.g. Reactive streams such as rxjava.

I agree python dependencies are a worldwide shame and eval() is very niche (but again should not be universality banned assuming good developers, maybe though one could conditionally ban it aka it would trigger a lint during code review that would need explicit validation.

As for the topic at hands, google style bans are insane e.g. No Exceptions lol

[f1shy]

I agree with this comment, and cannot understand why is downvoted. I would like the one that downvoted comments on why. My thinking, more or less in line with the comment is: instead of investing energy, time and resources in writing laws of what is allowed and what no (often without rationale). Use that time, effort and energy in educating developers, so that, if those prohibitions are really sensible, they will anyway refrain from doing that. You get the benefit of not having to change the bans. By doing regular code reviews, you can detect ill formed code, and discuss with the developers. Maybe some developer has something to teach to the "big experts" who write those documents?

[mrazomor]

What's easier: writing set of rules to drop language features or educating 10k engineers? It's difficult alone to have those engineers follow the style guide (even with help from linters etc).

Average engineer, in any company, doesn't care about the language they use. Just wants to get stuff done. And that's how it should be.

[f1shy]

My experience says, if you want to do one project. By all means, it's easier to have a standard where you drop features. -- But beware: you need either good engineers or you have to educate them, anyway.

If you have constant new projects, each one with very different requirements and needs, it will not be so easy to make a standard "one size fits all".

Also, again, you will not be doing "just one" standard, I would not subestimate the effort of such rulesets. You will have to the modify and modify it constantly (I know it from the company I'm, there are whole teams working on that, doing meetings constantly with stakeholders, and replying to exception requirements). In the long run, I would prefer to have good engineers, that do not need to be lead in each little step. --and having to check if they adhere to the rules!

I like the phrase: "If you think education is expensive, try with ignorance" Or: - I'm afraid to waste money educating our employees, and then they leave us - What if we do not educate them, and they stay?!

[mrazomor]

"no exceptions" is one of the best parts of Google style guide, IMO. Note that, banning of exceptions introduced returning status (error codes done right). It makes it easier to follow the code and makes the code more readable (but, you need a few macros, unfortunately).

[int_19h]

In a language like C++ returning status codes means that callers can and will ignore it, even when they shouldn't.

[zetafunction]

Since C++17, using [[nodiscard]] can help with that.

[jandrewrogers]

Indeed, Google's implementation of Status/StatusOr requires explicit handling of those objects, they cannot be discarded automatically.

[ncmncm]

OK if you like 10-15% performance loss off the top.

And incompatibility with the rest of the world.