Another rebuttal of Clean Code. Most of it makes sense if not overdone. There's the usual confusion around the "unit tests" term though, so take that section with a pinch of salt.

This is a good point. Idiosyncrasies are not necessarily a bad thing for naming things. Natural languages are fickle friends, you might need to rely to specific metaphors in order to disambiguate.

Interesting musing on the heuristics we use when solving problems. There are good advices in there to make progress and become a better developer.

Good reminder that /tmp has many security flaws built in.

Definitely a sound advice. You don't want to be confused when debugging something because it looks too much like a variable or a property name.

This is too often overlooked, but table lookups can help with performance if done well.

Finally a path forward for logic programming? An opportunity to evolve beyond Prolog and its variants? Good food for thought.

Nice paper which debunks the choice of the language as an important factor for energy efficiency. The previous papers had a too simple model, this one puts forth a more complete causal model. There are many factors at play regarding energy efficiency, the programming language itself is not really one of them.

If you still needed to be convinced you need to use std::array and std::span, here is the proof.

Interesting view about the LSP specification, where it shines, and where it falls short.

Good set of advices on naming variables, types, etc. Indeed this makes things easier to find in code bases.

Definitely a good advice, I see very complex expressions in if (or while BTW) conditions way too often. They tend to accumulate over time.

Interesting to see how far you can go preprocessing Python.

This is a good point. The DRY principle has value but the trick is finding the right time to apply it.

This is a very important distinction to keep in mind. It's one of those source of bad mistakes in C++.

This would definitely be a nice change to the Java language.

Ever wondered how attributes work in Python under the hood? Here is how.

An interesting Python construct to make iterators based on a simple function.

Not really Rust specific, this might be an interesting way to structure your code once async gets introduced. Should avoid some of the usual traps.

Obviously very opinionated. Still probably a nice list to pick from when making your own project specific coding guidelines.