4 ms·

I often wonder if I have a different definition of clean code than most people. To me clean code is code that's easy to change without breaking something, and t

I often wonder if I have a different definition of clean code than most people. To me clean code is code that's easy to change without breaking something, and that corresponds mostly to closely modeling the business domain. Of course other things matter as well but that's a whole book.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
K0SM0S 7y ago
That's my view as well, but it's built 100% from the trenches of real-world problem solving (I self-studied all of it, no formal academia in computing beyond a few intro classes). I think it's consensual by now (at least 'round these parts) that we've gone too far with clean and patterns and being too clever for your own sake (or that of your company) and even agile (once management took the concept over and changed it to its very opposite, kinda like democracy nowadays versus the Ancient Athenian spirit if you think about it). It's all pop culture by now, see that Silicon Valley show. The most tragic, in a sense, is that the people who created those concepts, who formalized them (extreme programming, uncle Bob, etc) very clearly stated that these are not "hard rules" and cannot work as such, ever — like we say "it's a 6" or "it's a 2" by instinct, there's no science there, no genius, just practical methods. The minute it became some sort of KPI the whole essence turns sour, possibly detrimental to the mission. When you approach things this way, with this prior or meta-knowledge so to speak, you can very much apply "clean code" principles to an otherwise very domain-driven model and software architecture; in fact one could argue you're making a true mathematical model — which is really not about people and compile times but about exactitude, precision, an as-honest-as-can-be mapping of a real phenomenon. Had we built physics like we approach "great code" nowadays, we'd have much prettier formulas that approximate truth in abstraction but never quite reach it. A treat for theoreticians, a nightmare for people with real-world, industrial problems.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

K0SM0S 7y ago

That's my view as well, but it's built 100% from the trenches of real-world problem solving (I self-studied all of it, no formal academia in computing beyond a few intro classes). I think it's consensual by now (at least 'round these parts) that we've gone too far with clean and patterns and being too clever for your own sake (or that of your company) and even agile (once management took the concept over and changed it to its very opposite, kinda like democracy nowadays versus the Ancient Athenian spirit if you think about it). It's all pop culture by now, see that Silicon Valley show. The most tragic, in a sense, is that the people who created those concepts, who formalized them (extreme programming, uncle Bob, etc) very clearly stated that these are not "hard rules" and cannot work as such, ever — like we say "it's a 6" or "it's a 2" by instinct, there's no science there, no genius, just practical methods. The minute it became some sort of KPI the whole essence turns sour, possibly detrimental to the mission. When you approach things this way, with this prior or meta-knowledge so to speak, you can very much apply "clean code" principles to an otherwise very domain-driven model and software architecture; in fact one could argue you're making a true mathematical model — which is really not about people and compile times but about exactitude, precision, an as-honest-as-can-be mapping of a real phenomenon. Had we built physics like we approach "great code" nowadays, we'd have much prettier formulas that approximate truth in abstraction but never quite reach it. A treat for theoreticians, a nightmare for people with real-world, industrial problems.