I disagree. I've seen very complex boolean expressions and they were clearly code smell. Sometimes acceptable but definitely a fertile area for refactoring.
Their example is crap to be fair - two comparisons is not complex.
There are arguments to be made either way, but normally you’d scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.
Sounds like you agree with that one to me? I'm not sure I follow their arguments about regions there (I've never used regions), but the example of declaring a variable in a block way before it is every used is spot on. I've seen code written like that and 99% of the time it's a bad idea. I think a lot of it comes from people who learnt C where you have to do that (or maybe Javascript which has weird rules for var).
Suggest writing a custom class to do what most languages can solve with inheritance or even better: the ? syntax.
Yeah I'll give you that one. They even suggest using Optional as a solution, which is what their "smelly" code did in the first place!
Yes, it can be annoying. No, clarity is more important than insisting on removing that extra underscore.
Not sure what your point is here. Of course inconsistent naming is a code smell. Do you want inconsistent names?
They’re advocating the use of a function to replace an expression. Sometimes this works, but the task of a boolean expression is not always easily expressed in a couple words. And so you can end up with misleading function names. Instead, just put a comment in the code.
Erm, yeah that's why this is a code smell. They aren't saying never have complex boolean expressions - just that if you do you'd better have a good reason because probably you'd be better off splitting it up into named parts.
callback hell - Not even a code smell. It’s an issue from back when languages like JavaScript didn’t support promises yet, but callbacks were popular.
Any specific ones? I've seen this before and I thought I would feel the same way as you before I read them, but actually the vast majority are pretty basic things that are not really arguable.
It's definitely nice to have a list like this to point inexperienced colleagues to in code reviews. It's a bit more authoritative than "trust me bro, I've written a lot of code".
That's the "say what you're going to say, say it, then say what you said" advice from school. It's ok if you don't know any better, or maybe for particularly boring work presentations, but it isn't a golden rule that most people blindly repeating it think it is.
Think about the best presentations you've seen. They never do that. They're engaging enough that you don't need repeat things three times.
That has XML semantics, which isn't what people want in the vast majority of cases. They want JSON semantics because it matches programming language object models.
The problem is there aren't really any good alternatives that have as widespread support. I've looked at lots and always found some annoying flaw that JSON or YAML don't have. I mainly want good support in Python, Rust and VSCode.
JSON5: This is my ideal alternative but it has surprisingly poor support. No good VSCode extension. There's a Serde crate but it's not very popular.
Jsonnet: This has great VSCode support and support for lots of languages including Rust, but for some inexplicable reason they won't let you use it with Serde just to load documents.
TOML: This is just not a good format. It's ok for very basic things but any level of nesting and it becomes even worse than YAML.
Cue: Only supported language is Go.
There isn't really a perfect option at the moment IMO.
If I'm using Rust I tend to go with RON at the moment. Sometimes I do use YAML but I write it as JSON (since YAML is a superset of JSON) with # comments.
Also never output YAML from your programs. You can always output JSON instead which is better.
You can do backwards compatibility and make breaking changes to fix bugs. All you need is an opt-in "target version". CMake and Android are good examples of this.
There's one called Energize on F-Droid already that's decent.
The problem is the food database will never be as good as the commercial versions. MFP is trash but MyNetDiary is very good and doesn't have obtrusive ads. It nags you to upgrade to premium occasionally but it's not too bad.
Unless you solve the database problem magically I don't think there's much point...
Well I'm no fan of Python either but it doesn't describe itself as a scripting language (and neither does Ruby) so I think you're way off there.
And I dunno about Ruby being a better Python. It looks way worse to me. In particular the story for static type annotation seems pretty dire. The syntax is worse, it's less popular, and even slower!
I can believe the tooling is better though. Python's is abysmal (unless they officially adopt uv - ray of hope there but I have zero faith the Python Devs would make such an obvious decision).
Very good points. A codebase that gets this VERY wrong is Gitlab. I think it might be a dumb characteristic of Ruby programs, but they generate identifiers all over the place. I once had to literally give up following some code because I could not find what it was calling anywhere. Insanity.
Another point: don't use - in names. Eventually you'll have to write them down in a programming language, at which point you have to change the name. CSS made this mistake. foo-bar in CSS maps to fooBar in Javascript. Rust also made this mistake with crate names. A crate called foo-bar magically becomes foo_bar in Rust code.
He's right that it's probably harder for AI to understand. But wrong in every other way possible. Human understanding should trump AI, at least while they're as unreliable as they currently are.
Maybe one day AI will know how to not bullshit, and everyone will use it, and then we'll start writing documentation specifically for AI. But that's a long way off.
I wouldn't recommend it. I actually looked up COBOL jobs a while ago, and while they paid more, it was only like 20% more - not enough to make it worth it IMO.
There is no rule. Smells are not rules.