4 ms·
GP said > Especially because Clean Code doesn’t actually seem easier to read or indeed maintain If that is true, then there is indeed no point in applying Cle
by funcDropShadow 2y ago
GP said
> Especially because Clean Code doesn’t actually seem easier to read or indeed maintain
If that is true, then there is indeed no point in applying Clean Code. But I disagree with GP that Clean Code leads automatically to bad performing code. That depends on your language and execution environment. A JVM is very good at effectively removing vtable indirection if they are not needed at runtime.
- dwattttt 2y agoI'd also argue that even if vtable indirection can't be removed, it's unlikely to be a notable part of your performance profile, at least in the general case. Profile! You might instead see the hasher for your hash table has a much bigger.
- tovej 2y agoI don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one. There's also other issues with this paradigm, like creating objects out of the arguments to a function. That not only makes your code less maintainable (what if you need a subset of the variables), but now you'll have to drag all that data to each function you create. Clean code is, IMO, worthless, data- and domain-driven design practices accomplish the goals of clean code better than it the paradigm itself does, and also improve other considerations like correctness and performance.
- renox 2y ago>I don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one. An interesting question, but a SoA isn't necessarily better than an AoS: it depends on the access pattern, so the question is whether this optimisation could be added as a part of PGO..