Whatever 'Clean Code' you write now, it'll be shit eventually and in need of a complete rewrite

New code is O(n log n), but the time benefits only kicks in when n is above 1 trillion. Otherwise it’s much slower.

Programming is the gradual collection of mantras.

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them...

It makes no sense.

Ahhhh, the ol' "dynamic languages are better than static languages because I have tests that check for different types" argument.

For example, in Swift, if you declare a function to throw an exception, then by God every call to that function, all the way up the stack, must be adorned with a do-try block, or a try!, or a try?

I agree with him on this point. Sounds similar to how it’s in Java, and I hate it. I always wrap my exceptions in a RuntimeExceptions because of this.

I disagree with him the rest of the post. The job of the programmer is to communicate the intent of the program. Both for others and for yourself. The language provides the tools to do so. If a value is intended to be nullable, then I would like to communicate this intent. I think it’s good when a language provides this tool.

Tests don’t communicate the intent of the code. Tests can’t perfectly validate all the possible edge cases of the system either.

His take strangely acknowledges that defects are caused by programmers, yet doesn’t want to improve the tools we use to help us not make these mistakes. In summary, git gud.

Experience has taught me that I’m awfully good at finding and firing foot guns, and when I use a language that has fewer foot guns along with good linting, I write reliable code because I tend to focus on what I want the code to do, not how to get there.

Declarative functional programming suits me down to the ground. OOP has been friendly to me, mostly, but it also has been the hardest to understand when I come back to it. Experience has given me an almost irrational aversion to side effects, and my simple mind considers class members as side effects

To my knowledge, the Rust's book actually encourages writing as many automated tests as you can, as the compiler can't catch every type of bug in existance.

rather strongly typed Java.

[In Java] you can also violate many of the type rules whenever you want or need to

Okay. Well maybe being able to not spell out types every single time would also count as not burdening the programmer ¯(ツ)/¯

I bought Clean Code when I started learning programming, some of it was useful, but now I understand that it was too opinionated for a beginner

Edit: also

Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job[?]

It is language's job to enforce risk management wherever possible, humans are demonstrated time and time again to be poor at risk management (same for the other questions like 'whose job it is to check for nulls'

Edit2:

Defects are the fault of programmers. It is programmers who create defects

… and that is why he proposes to not help programmers with language means. I never thought that views of how problems should be tackled might differ so much while having in mind the same reasons and goals.

Albeit I do agree that one must write tests, even if language helps, not everything can reasonably be automatically checked

wtf did i just read?

Funny how he is actually now a fan of Clojure yet the examples in his book are actually full of mutating data and side effects. And Rich Hickey also stressed that tests are no silver bullet.

Java is a fine choice. Much prefer it over pseudocode.

I think it’s telling that none of his talks even make it all the way through his SOLID acronym, he sorta just trails off when he’s out of time.

His ideas were real big in the ruby community back when I was learning it, and if I ever go back that code is such a pain to work with. Almost impossible to follow the logic, inheritance everywhere, and I even thought metaprogramming was a good idea. Tests are the only reason that code has any reliability at all.

Now most of my code is procedural or functional, favors composition over inheritance, and is colocated as much as possible.

death by specificity is a thing...
HTTPServletRequest has a fuckton of methods but 90% of them could be eliminated if one treated the data as a simple fucking map instead of creating 4 methods for each key in every record of your schemas.

Sorry, I still don't really get the hate.

Most of the good points are common sense.

I use what I learned from watching a talk by him on clean code and I had to learn some stuff. It might be "common sense" for experienced developers. But it certainly doesn't come naturally that "functions should do one thing" to first time coders. The thought processes of when the software was developed usually isn't the best way the code should be structured in the end. But that's usually how beginners code.

It’s mostly based on what he feels is good.

In most diciplines, experience in the field is what makes the knowledge of the field. You don't always have to be able to explain why good practice does what it does.

Also: I know of some examples, where he clearly explains his reasoning, e.g. why comments shouldn't explain how the code works. (Because they're not going to be updated, when the code will be)

As a programmer, I want all relevant logic of a method to be neatly collected in one place - not scattered around deeply nested method calls.

Either you misrepresent him, or you get a hard nope from me. Staying on one layer of abstraction is most likely my most important principle of writing understandable and maintainable code.

Thanks. Didn't know the last bit. Ffs =.=

While we’re giving advice on good reads, I foudn “Code Complete” to be much more useful than “The Pragmatic Programmer” (also about 10x the size).

personally I'd sum it up this way: it is usually enough to abstract two parts of your code: the repetitive stuff and the stuff that can be separated from external dependencies like db or network. That should be enough to ensure readability and that you can test it properly and not have to deal with rewriting half your codebase when you decide to change an external dependency.

Can you give examples? I genuinely can't think of how the principles applied with proper restraint not to overdo it make code hard to maintain. But I've only watched his talk a few years ago - not the book.