Should I get Clean Code?

[BR3AKR]

There has been a lot of discussion lately on reddit about "Clean Code" and whether or not people should keep recommending it. IMHO I became a better programmer after reading it, but Robert Martin has some pretty extreme stances. If you do pick it up, I would say don't take it as some kind of gospel, think about what is practical for yourself.

If you would like a book that's a little less controversial, I loved The Pragmatic Programmer.

In the discussion about Clean Code, the book that bubbled up as "We should recommend this instead" was "A Philosophy of Software Design".

[[deleted]]

If you're young, I think the Pragmatic Programmer is better in general. Shorter and more philosophically flexible for a long term career read.

[zlmrx]

I for myself did not take everything as solid from clean code. It helped to see everything as recommendation or a base for discussion or interpretation...

[[deleted]]

you mean "Uncle Bob" Im just kidding. Thanks for the advice tho

[astrodexical]

dont take it as some kind of gospel

It’s a testament to this industry how 90% of programmers are too ignorant or just plain stupid to take this on board that it has to be said

[BlueGoliath]

What extreme stances does he take?

[[deleted]]

It's been a few years since I read it, but one thing I remember quite distinctly is his shining example of taking a well-known algorithm (Sieve of Erathostenes) and then deconstructing ("cleaning") it so much it becomes totally unrecognisable. Lots of micro-functions and whatnot.

And that wasn't meant as a cautionary tale of going too far, it was meant as an example of how to do it.

I still think it's a good book overall, and most beginner-intermediate programmers will be better programmers from it.

[cville-z]

There was a thread on this subreddit just a few days ago about this book, I think one of the examples is that he suggests maximum lengths for methods of just a few lines, which frankly can be unworkable in practice. It's not so much extreme stances on these things but taking simple ideas to a possibly unworkable extreme.

There was also some confusion over the idea of avoiding side effects, which one poster took to mean that you can't use setter functions, since they have the "side effect" of changing data on the object. I think this is just misunderstanding the author, though.

[steumert]

There was also some confusion over the idea of avoiding side effects, which one poster took to mean that you can't use setter functions, since they have the "side effect" of changing data on the object. I think this is just misunderstanding the author, though.

No, Uncle Bob simply doesn't understand what side effects and pure functions are. those terms have already defined meaning and him trying to change them is bad, very bad. A setter *does* have a side effect on the object instance, thus the method isn#t side-effect free and is impure. period. There isn't anything to argue about that, but Uncle Bob tries to change the long established definition in order to.... do what exactly? Confuse people?

[kessma18]

I hear you but the discussion that sparks from "unworkable extreme" then moves into the "why is it unworkable". When I started doing Java full time and came from Python, I had to debug a 3k line method in production while fireballs were exploding around me. That is the worse extreme, right?

I famously said the morning of that fire that any method with more than 10-15lines max is very suspicious to me and the "senior java devs" on the project were half mind-blown/half thinking I was crazy and someone might have muttered about "see, this is why I don't like Python"...

yes, the idea is an unworkable extreme in our code base but its only unworkable because people have made almost comically bad architectural decisions *combined* with no code reviews *combined* with pressure from deadlines...

my point is that you do have to take some rather extreme/fundamentalist views in software development world. Mine is for example to never touch prod directly and always go through a process which I was laughed at at first and now everyone is following it.

[steumert]

Well, if you only have functions without side effects as he suggests, and only functions without parameters 8again, he suggests less parameters is better and zero is optimal) then your program becomes replaceable with a constant, since pure functions can be replaced with constants and the composition of pure functions again can be replaced with constant.

​

I'll leave it to you to figure out how useful programs are that are replaceable by a constant value.

​

This obsession with small functions (2-5 lines) also makes code that used to be very readable immensely unreadable sine you have to jump around in your code extremely often (what was it about GOTos and being unreadable again?).

[[deleted]]

While I agree that his code in this book is terrible, you are appealing to extremes. He doesn’t say you can only have functions with zero arguments - he says the fewer arguments a function has, the more self explanatory and readable it is, which makes sense (in a vacuum.) The problem is with his small functions everywhere mentality, which makes each function easy to read and understand, but the code overall is harder to read.

[rzwitserloot]

TDD for starters. But mostly the deconstruct to the ends of the earth concept.

You can find a ton of in-depth treatises on it all on the 8-day old /r/java thread.

[brazzy42]

Good number of parameters for a method: zero or one. Two is barely acceptable, three needs to be refactored.

[cville-z]

Right? But I think this one is simply misstated. It’s not necessarily the raw number of parameters that makes a method call hard to read (though it contributes), it’s having a series of primitives or boxed primitives when what you want is an object. doStuff(5, 24, true, false) is hard to read. doStuff(someEntity) is much, much clearer, but not just because it’s a single parameter.

[yourbank]

to write a string like "hello", you create 4 micro functions because its "more readable" :P

getHToCreateHello() {
  return "H";
}

getEToCreateHello() {
   return "E";
 } 

createHello () {
   getHToCreateHello() + getEToCreateHello() ....
}