Hacker News Reader

Comment by katamaster818 | Hacker News Reader

This isn't exactly a repo to look at, but the book "Clean Code" is a fantastic read for learning how to write good code. It does have a lot of examples in it, and does a great job explaining everything. https://github.com/jnguyen095/clean-code/blob/master/Clean.C...

View on HN

https://qntm.org/clean has a great discussion of all the things that are wrong with Clean Code.

Interesting read. I read a companion book (or is it wholly unrelated?) called Clean Code for Python and I learned a whole lot! That book improved my Python more than anything else, honestly. That being said, I agree with the critique that obsessively committing to DRY is throwing the baby out with the bathwater.

I don't like clean code, and like the author I find the things presented in Clean Code to just make incredibly inscrutable code. The worst code bases I have seen have been the ones with no code plans at all, and the ones that use Clean Code and Gang of Four like a bible, both are equally mazes of spaghetti. Clean Code I really just don't agree with, and I think this author lays it out well. Special design patterns and tons of polymorphism usually end up creating multiples of complexity in the effort to reduce DRY at any cost (and often are abstractions that are only ever used one or two times anyways).

Ultimately I think the single most important rule for clean code is: skinny controller, fat model. If you are doing batch data, then this applies still I think. You should have all of the logic you can in the model, avoid data objects. And the code paths that alter things should be as thin as possible. I honestly think it is better to have a 5k line model if it avoids more.

The most unlcean code I have seen usually falls into the abstracted out processes in financial instutitons where they follow Clean Code advice and everything are a bunch of functions passing around some big fat objects full of getters and setters, and changing any functionality means adding changes somewhere in the process to check state and alter the state, which leads to loops and if statements everywhere to see which account type it is at each point etc.

But in OOP programming its supposed to be objects sending messages to each other. Every object should know everything about itself, which is what a fat model demands. Any more abstraction than that seems to get in the way.

The popular OOP seems to be exactly the opposite of what OOP was meant to be. If you get into the original intentions, it honestly starts to sound more like FP.

Absolutely agree.

Popular OOP passes Structs around (they just call them records or POJOs or whatever) through a bunch of "classes" that do x. But you could rewrite the code from Java or C# or C++ into C or Cobol and it basically is the same. Its just imperative code with classes as a nice way of getting rid of globals.

The side effects example is exactly where I put down the book. I briefly questioned whether the book is supposed to be satire.

Clean Code is dreadful, or at least the programming examples are.

It was a good book of its time in that it was influential and encouraged people to think more deeply about how to make code readable, but even when it was published I thought it had some terrible advice.

It's probably still just about worth reading, as long as you ignore all the code examples and appreciate that some of the thinking is out of date, and a lot of the rest is controversial at best.

I also find the style grates, as "Uncle Bob" is far too full of himself and e.g. "rips apart" someone's code to produce a worse refactor.

There’s so much conflicting advice in this book (like saying functions should be immutable then also saying the ideal function has 0 arguments, apparently mutating the class doesn’t actually make the function mutable to Bob Martin!), and the code examples themselves are horrible (the prime number generator for example).

I’ve heard people say it’s a good book if you just ignore all the bad stuff, but how are you supposed to know what the bad stuff is if you’re a beginner? I think it’s time to stop recommending this.

> like saying functions should be immutable then also saying the ideal function has 0 arguments, apparently mutating the class doesn’t actually make the function mutable to Bob Martin!

What does "functions should be immutable" have to do with mutating classes?

I should have been more specific, the way Bob Martin phrases it in the book is functions should have 0 side effects. Then he shows an example at the end of the chapter where the entire example works by creating a giant class full of member functions that mutate the owning class. I (and I think most people) assume that a function with 0 side effects means that if you call the function, the state of the object should be the same before and after the function call (and the rest of the external system should remain unchanged). But, according to the examples in the book, it seems like Bob Martin only considers it a side effect if some external state is modified as a result of the function call.

The best example of a function without side effects would be sin(x). You call the function with an input and it returns a completely new output. The function should be thread safe and easy to isolate because it never touches any outside state.

I do not think that book is a good suggestion for good or readable code, and also there is this (which in many situations will not matter, but still): https://www.computerenhance.com/p/clean-code-horrible-perfor...

Someone who does writes quite clean code is in my opinion Tsoding: https://www.youtube.com/@TsodingDaily Strongly recommend his YouTube channel!

Reply on news.ycombinator.com