magic_lobster_party

I didn’t read everything, but I mostly agree with the author, especially on this point:

While you can definitely abuse exceptions, functional-style error values are not a one-size-fits-all solution.

There are time and place for both. I think exceptions are good for bigger errors. Like database connection errors. Things that shouldn’t happen without any easy backup plan. Those errors might need to be escalated as high as possible where proper action can be made (like resetting the database connection and everything relying on it).

Functional style is great for smaller stuff. Like key not found in hash maps. In many cases there might be good defaults that can be used instead.

It’s a concept of a plan

Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.

Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.

I agree, and I count that as “key information that’s difficult to understand from the code”.

IMO, comments should be used to provide value to the code. If they’re used too much, then readers of the code will more likely stop reading them altogether. They already got what they need from the code itself and the comments usually don’t add much value.

If they’re sparse, then that’s a good indication they’re important and shouldn’t be missed.

I think comments are good as a last resort when it’s difficult to communicate the intention of the code with other means.

If I find code that’s hard to understand, I’ll first try to find better variable or function names. Often this is enough.

If it’s still too difficult to understand, I try to restructure the code to better communicate the flow of the code.

If that doesn’t help (or is too difficult), then I might add a comment explaining key information that’s difficult to understand from the code.

Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.

It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.

In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.

The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.

In your example, the declaration of ArrayList look like:

public class ArrayList extends AbstractList implements List {
}

The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.

Compare it with my solution:

public class ArrayList implements List {
    private AbstractList = new AbstractList();
}

Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.

If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.

I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.

Ask Bjarne to add interfaces enough many times until he gives in.

On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.

In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.

I’m not sure why you would use abstract classes without data. Just use interfaces.

So things like abstract classes are mostly absent from my codebase.

I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.

There’s a special place in hell for those who set an upper limit in password lengths.

0.02% means you’re saving a fraction of a second for every hour of runtime. A lot of adding up is required to make it significant enough for anyone to notice.

Better to spend that time and effort on things that actually bring value. These kind of micro optimizations can also make the code unnecessarily complicated and difficult to work with, which is a hindrance for the optimizations that truly matter.

The IDE can assist you before it even becomes a problem, so even more time saved.

Optimizing CPU usage by 0.02% is something only the truly deranged do