Robert Martin and John Ousterhout have a conversation about Clean Code[0] versus the approach in A Philosophy of Software Design.
> Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far.
My take is that that Clean Code has some good advice for enterprise style software projects. It is incredibly prescriptive but sometimes that's not such a bad thing. In my experience it's worth it in uncoordinated/inexperienced teams who would otherwise produce an undisciplined mess of code.
Stick with it if it works for you as long as you don't go around bashing other people for not doing it the "right" way as many clean coders do. The dogma surrounding what amounts to a set of preferences and design trade-offs is what makes Clean Code so off-putting, especially if you have slightly different preferences.
> Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far.
My take is that that Clean Code has some good advice for enterprise style software projects. It is incredibly prescriptive but sometimes that's not such a bad thing. In my experience it's worth it in uncoordinated/inexperienced teams who would otherwise produce an undisciplined mess of code.
Stick with it if it works for you as long as you don't go around bashing other people for not doing it the "right" way as many clean coders do. The dogma surrounding what amounts to a set of preferences and design trade-offs is what makes Clean Code so off-putting, especially if you have slightly different preferences.
[0] - https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...