> Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends Getting a bit des

> Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends Getting a bit desperate here, eh? On one hand, having tables of function pointers does not introduce any code constraints, you can switch to switches or anything else at a moment's notice; class hierarchies are much more rigid (some random Torvalds quote, "all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app"). On the other hand, Clean Code is fundamentally tied to OOP and classes. Here, straight from the horse's mouth [1]: "This expectation of polymorphism is the essence of OO programming. It is the reductionist definition; and it is inextricable from OO. OO without polymorphism is not OO. C and Pascal programmers (and to some extend even Fortran, and Cobol programmers) have always created systems of encapsulated functions and data structures. It does not require an OOPL to create and use such encapsulated structures. Encapsulation, and even simple inheritance, is obvious and natural in such languages. (More natural in C and Pascal than the others.) So the thing that truly differentiates OO programs from non-OO programs is polymorphism. You might complain about this by saying that polymorphism can be achieved by using switch statements or long if/else chains within f. This is true, so I must add one more constraint to OO. The mechanism of polymorphism must not create a source code dependency from the caller to the callee." In short, C is not OO because it doesn't do polymorphism (as understood in the context of Java-like OO languages rather than a mystic "it kinda looks and does the same as OO, thefore C is OO"). Furthermore: "FP and OO work nicely together. Both attributes are desirable as part of modern systems. A system that is built on both OO and FP principles will maximize flexibility, maintainability, testability, simplicity, and robustness. Excluding one in favor of the other can only weaken the structure of a system". Which is to say, if you don't do OO then you're not doing Clean Code. On a side note, Robert Martin obviously thinks he could write a Linux that's more flexible, maintainable, testable, simple and robust, but he's leaving it as an exercise to the reader. https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html > You're spending an unaffordable amount of your finite engineering resource on handling other people's problems in all of your code if you insist on peering inside everything It's not quite so dramatic, you don't need access to STL's internals, just the structures you're working with anyway. To simplify: if you have an algorithm that deals with shapes then don't abstract away the concrete types, don't try to impose a taxonomy, don't pretend there's a magic shape interface that generalizes everything, don't try to fit the square box in a round hole. Instead, allow the algorithm to deal with concrete types. This is in fact the most flexible approach - you won't find yourself having to rethink your class hierarchy when one of your classes doesn't neatly fit into the general picture. I've been in the situation where at the end of a project it becomes very obvious that the chosen class hierarchy is actually unsuitable for easily adding more features and improving performance, but by that point the effort to restructure the hierarchy is equivalent to a rewrite. But hey, we had Clean Code. The key point is that Casey's approach allows you to easily optimize for performance if needed; Clean Code does not. > Casey and Jonathan Blow are too slow to deliver products Fine, take Mike Acton. Same ideas, except he had to ship games on demand. You won't catch him doing Clean Code.