4 ms·

For me, I bought "Clean Code" because it was, at the time at least, quite highly recommended. After being rather confused for a while, I finally stopped reading

For me, I bought "Clean Code" because it was, at the time at least, quite highly recommended. After being rather confused for a while, I finally stopped reading right around page 141 when I realized that the reason his examples looked awful were because they were. In that section of the book, he takes a Java port of Donald Knuth's PrintPrimes program, and refactors it. But in doing so, he actually breaks it. He moves state out of local variables and parameters and makes them all static fields, and then refactors the code into long-winded methods that specifically perform side effects or operate on those fields (names like isNotMultipleOfAnyPreviousFactor(), isLeastRelevantMultipleOfNextLargerPrimeFactor()). But the simple act of moving state that would otherwise be part of the stack frame into static fields means he has changed the behaviour of the code - it is no longer thread safe! calling it from different threads will have undefined results because all threads will be operating on the static fields. He demonstrably made the code worse!. It invalidated the entire book for me at that point. Here's "Uncle Bob" trying to pretend to be some aged, skilled, craftsman hand guiding us young, ignorant whippersnappers into being proper craftsman and not only can't he properly refactor a simple prime number sieve as a demonstration, but he's so blind to awful code that he doesn't even see it in his awful example enough that it gets published in the same book that complained about programmers who don't have "code-sense". Mistakes and "errata" are one thing, but when he makes such a big noise about "do it right the first time" and then has an example where he refactors and literally breaks something, that's another.

Scubabear68 2y ago
I started reading the code Martin wrote with his son for the “FitNesse” acceptance tracking framework. The code was simply God awful. Nearly every method was tagged ad “throws Exception”, no comments, and the famous endless sea of classes with only a few lines of code per method. The code itself ran with constant exceptions filling up the logs. This was going back over a decade or more when I looked at it. You can see his lineage of trying to sell consulting services and books all the way back to the comp.object Usenet groups back in the 90s. Sadly he still commands big fees to speak at various conferences and companies, I was very disappointed when he spoke at Bloomberg many years ago when I worked there.
jrpelkonen 2y ago
Interestingly enough, John Ousterhout was a recently on Book Overflow podcast and he says he uses this very refactoring but on reverse to teach good software design. So it’s good for something!
b3orn 2y ago
In my opinion the only good part of that book is the title.
- _gabe_ 2y ago
  I even hate that the title got popularized. Code isn’t “clean” or “dirty”. It works or it doesn’t work. That’s the most important aspect. Another very important aspect is that It’s readable or unreadable. Readable code may be very long winded, but I would much rather have that than somebody’s idea of a “clean” concise very abstract piece of logic. I hate when I get comments on a PR talking about some subjective piece of code suggesting an alternative that they think is “cleaner”. How clean a piece of code is shouldn’t be a part of consideration while reviewing any code. Instead, like I said before, the only thing that really matters is if it works and if it’s readable. I wonder how many junior engineers have been bogged down with pointless PR comments over the years because of this idea that code can somehow be “neat” or “clean”.
  - b3orn 2y ago
    I always took it more as readable code.
wredue 2y ago
I mean. It’s not like people pushing “side effects” (read: literally any change at all) aren’t also being overtly dogmatic, and writing utterly terrible code. Uncle bobs book didn’t age well, but neither will the dogmatic stances on immutability and side effects.
- bc_programming 2y ago
  In this case, By "side effects" I mean non-obvious changes to the static state, Where a seemingly simple function will both rely on static fields to evaluate it's result as well as make changes to various other fields that will subsequently change the result of that function going forward. I don't think one needs a dogmatic adherence to immutability and avoiding side effects to find that to be undesirable.
  - LorenPechtel 2y ago
    What's especially important is non-obvious state. I was trying to use a function. You had to create an instance of it to use it, but I was using one method that by appearances should have been static. You feed it an input, it gives you an output, there's nothing to remember. I was calling it from multiple threads--occasional corruption. There must have been something being stored into the object but I have no idea what or why.
  - wredue 2y ago
    I agree. Just letting you know that, most likely, the people you are learning about “side effects” from don’t actually mean “side effect” in the colloquial sense of “state changes beyond the expectation”. They mean literally any change at all. If your function is named addOne(&x), then they consider the result of x being one greater to be a “side effect”, whereas I suspect actually sane people such as yourself would not see that as a side effect. This type of definition fuckery is one reason (among many), that I’ve come to fully disrespect functional programming communities. One thing that also needs to be understood is that side effects (to your definition) are not explicitly bad things. Side effects ignoring boundaries, ignoring APIs, holding references, etc are probably mostly bad though. In fact, in gaming, providing hooks to empower side effects is often explicitly good for granting designers mechanic freedom.

Scubabear68 2y ago

I started reading the code Martin wrote with his son for the “FitNesse” acceptance tracking framework. The code was simply God awful. Nearly every method was tagged ad “throws Exception”, no comments, and the famous endless sea of classes with only a few lines of code per method. The code itself ran with constant exceptions filling up the logs. This was going back over a decade or more when I looked at it. You can see his lineage of trying to sell consulting services and books all the way back to the comp.object Usenet groups back in the 90s. Sadly he still commands big fees to speak at various conferences and companies, I was very disappointed when he spoke at Bloomberg many years ago when I worked there.

jrpelkonen 2y ago

Interestingly enough, John Ousterhout was a recently on Book Overflow podcast and he says he uses this very refactoring but on reverse to teach good software design. So it’s good for something!

b3orn 2y ago

In my opinion the only good part of that book is the title.

_gabe_ 2y ago
I even hate that the title got popularized. Code isn’t “clean” or “dirty”. It works or it doesn’t work. That’s the most important aspect. Another very important aspect is that It’s readable or unreadable. Readable code may be very long winded, but I would much rather have that than somebody’s idea of a “clean” concise very abstract piece of logic. I hate when I get comments on a PR talking about some subjective piece of code suggesting an alternative that they think is “cleaner”. How clean a piece of code is shouldn’t be a part of consideration while reviewing any code. Instead, like I said before, the only thing that really matters is if it works and if it’s readable. I wonder how many junior engineers have been bogged down with pointless PR comments over the years because of this idea that code can somehow be “neat” or “clean”.
- b3orn 2y ago
  I always took it more as readable code.

wredue 2y ago

I mean. It’s not like people pushing “side effects” (read: literally any change at all) aren’t also being overtly dogmatic, and writing utterly terrible code. Uncle bobs book didn’t age well, but neither will the dogmatic stances on immutability and side effects.

bc_programming 2y ago
In this case, By "side effects" I mean non-obvious changes to the static state, Where a seemingly simple function will both rely on static fields to evaluate it's result as well as make changes to various other fields that will subsequently change the result of that function going forward. I don't think one needs a dogmatic adherence to immutability and avoiding side effects to find that to be undesirable.
- LorenPechtel 2y ago
  What's especially important is non-obvious state. I was trying to use a function. You had to create an instance of it to use it, but I was using one method that by appearances should have been static. You feed it an input, it gives you an output, there's nothing to remember. I was calling it from multiple threads--occasional corruption. There must have been something being stored into the object but I have no idea what or why.
- wredue 2y ago
  I agree. Just letting you know that, most likely, the people you are learning about “side effects” from don’t actually mean “side effect” in the colloquial sense of “state changes beyond the expectation”. They mean literally any change at all. If your function is named addOne(&x), then they consider the result of x being one greater to be a “side effect”, whereas I suspect actually sane people such as yourself would not see that as a side effect. This type of definition fuckery is one reason (among many), that I’ve come to fully disrespect functional programming communities. One thing that also needs to be understood is that side effects (to your definition) are not explicitly bad things. Side effects ignoring boundaries, ignoring APIs, holding references, etc are probably mostly bad though. In fact, in gaming, providing hooks to empower side effects is often explicitly good for granting designers mechanic freedom.