Comments by "T J" (@TJ-hs1qm) on "Stop Recommending Clean Code" video.

I'm not defending Robert C Martin here, but all he did was to collect a bunch of widely accepted programming rules (mainly from the OO world of his generation**) under his brand Clean Code. I think each of these rules has lineage in the early days of (OO-) programming. So these rules are decades old, but many still hold true in the context of business applications. ** The DRY principle idea for example is from the 1999 book The Pragmatic Programmer, and in the 2nd editions they even try to clarify the original idea... which goes beyond copying & pasting of code, as they see it.. paraphrasing “DRY Is More Than Code" In the first edition of our book, we failed to adequately convey the full meaning of "Don't Repeat Yourself" (DRY). Many misinterpreted it as solely applicable to code, believing it meant "avoid copying and pasting lines of code." While this is a part of DRY, it's a relatively minor and insignificant aspect. DRY goes beyond code and encompasses the duplication of knowledge and intent. It's about expressing the same idea in different places, perhaps in entirely different ways.
1
not that it matters but I remember the open-closed principle from way back, way before Robert C. Martin ever used it. It was Bertrand Meyer who coined the term and has been a rule in OO programming ever since.
1
When I think about how to design a function I look at these factors Can I cut down the dimensions of my function (as in dimension reduction)? Because reasoning about one input parameter is significantly easier than ten. I also take a look how my input values correlate. When they change, do they change independently or not. For example, when a person moves to different home, the street name, number, zip code and city tend to change simultaneously, but never their e-mail address. So maybe factor those out in something we call "Address Type" and "E-Mail Type" representing these uncorrelated multi dimensional concepts, so that I can pass in things that are highly correlated into my function (address and email), thereby reducing the number of input parameters and my cognitive load. After having figured out the degree of correlation between my input variables, I decide whether my function should really depend on two orthogonal variables, which could change for different reasons, meaning that my function is maybe doing too much. But all this always depends on the use case. If someone would move on to work for another company the work e-mail is probably also going to change with the address, which makes the e-mail correlate again with the address.
1
Our industry could have gone Green a long time ago, but we keep wasting compute and cooling energy because of how inefficient our code is. Overall I think, that criticizing these rules is a very good thing. But then again, you will always have to deal with the... Jevons Paradox, named after the English economist William Stanley Jevons. It states that technological improvements that increase efficiency in the use of a resource will tend to lead to an overall increase in consumption of that resource, rather than a decrease. This is because the increased efficiency makes the resource less expensive, which in turn encourages people to use more of it.
1