4 ms·
> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that proba
by st3fan 4y ago
> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use.
Unfortunately this is just some catchy stereotyping that probably doesn't match reality.
- gjadi 4y agoI don't know. Before reading Casey, I'd say most, if not all, of my APIs would look like the "clean code" style. The process was "think about the model, design a class hierarchy that fits with the model, add the operations". Even if I don't think about extensibility, that's how I thought my code. Why? Because when I think about performance, I used to think about algorithms and I/O optimizations (for example batching). Now I'll look into this data-oriented programming-thing and see how that applies to my platform (embedded Java) :D
- jstimpfle 4y agoThe code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.
- loup-vaillant 4y agoThat's what you get with SOLID. Madness.
- deleted 4y ago[deleted]
- loup-vaillant 4y agoI've seen at least one embodiment of the stereotype 3 months ago. It wasn't pretty, I was able to shrink his code by a factor of 5, and make it more flexible in the process. Among other mistakes he had some idea of flexibility, put part of the infrastructure in place, and then utterly failed to use it, such that when it came to test he required a monkey patching framework for C (Ceedling) so he could mock what he almost already mocked in the source code. That's a fairly rare breed for sure, but the real problem was that nobody called him out. Well I did, but I'm no longer working there. I couldn't.