I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.

Consider this example:

try {
    File file = openFile();
    String contents = file.read();
    file.close();
    return contents:
} catch (IoException) {
}

Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.

We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.

One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.

Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.

What I’m saying is that it’s hiding too much of the control flow.

Compare it with this code:

public double calculateCommision(Sale sale, Contract contract) {
    double defaultCommision = calculateDefaultCommision(sale);
    double extraCommision = calculateExtraCommision(sale, contract);
    return defaultCommision + extraCommision;
}

This is about the same number of lines, but it communicates so much more about the control flow. It gives us an idea which data is involved in the calculations, and where we can find the result of all the calculations. We can make assumptions that the functions inside are independent from each other, and that they’re probably not relying on side effects.

This is also against clean code examples, because Uncle Bob seems to be allergic against function arguments and return values.

Academia has a disconnect with the industry when it comes to coding practices. Most teachers haven’t much industry experience. They don’t know how it is to maintain a 10 year old project using SOLID and clean code principles.

They just teach whatever has already been in the curriculum for decades. They don’t know that whatever they’re teaching is actually harmful in the industry.

Problem is that barely anyone use crypto as currency. Almost everybody treat it as a stupid get rich quick scheme.

It’s abstract art!

I heavily disagree it’s easier to write good code if you follow clean code. Especially if you follow his examples throughout the book. Most of his examples are just over engineered messes held together by side effects (even if he says side effects is a bad thing).

If he can’t write good code by following clean code, why should you? He even picked the examples himself and failed!

These kind methods hide too much.

Where can I find the commissions these methods calculated? Does extra commissions depend on the calculations of default commissions? Do I need to calculate default commissions before calling hasExtraCommisions? What happens if I calculate extra commissions if hasExtraCommisions return false?

There are so many questions about this code that should be immediately obvious, but isn’t.

The article goes into that. Clean Code has some good advice. But it also got bad advice.

Problem is, the good advice is basic. Anyone working in the industry will pick most of these up. All the good advice could be summed up in 10 pages or so.

The bad advice is incredibly bad - and in the worst cases even be counter productive. A newbie won’t be able to tell these advice apart. Some professionals might not either. So they adopt these techniques to their code, and slowly their code turns into an unmaintainable mess of spaghetti.

So no, the book shouldn’t be recommended to anybody. It has already done enough harm to the industry.

Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head

It has the exact opposite effect. It leads to code that doesn’t fit in your head.

Because his style of coding leads to code where everything useful are 10 levels deep in nested method calls. If I want to understand how the code works and how my changes will affect the overall picture, I need to keep a dozen methods in my head and how all of these are connected to each other.

And he’s mostly working with global states, so knowing where variables are assigned is just a huge pain.

So many times I’ve looked into code like this where I finally find what I’m looking for, only to forget how I even reached this part of the code. So I need to backtrack to remember how I got there, but then I forget where that damn thing I was looking for is. And I go back and forth until I figure out a mental model of the code. It’s awful!

Compare that with just having one big method. Everything is in front of me. I don’t need to keep that many things in my head at the same time, because everything I need is right there in front of my eyes.

Sure, sometimes breaking out to separate methods can make it easier to communicate what the code does and the boundaries of each scope, but if it’s overdone it leads to code that’s impossible to work with.

It’s generally considered a fact that Linux, along with many other open-source software projects, are more efficient than their propriety closed-source counterparts

This is not necessarily true. Linux had trouble with Nvidia Optimus, which is a GPU technology that seamlessly switches between power modes. Well, that is if it works properly, which it didn’t for Linux. I haven’t heard it in a while, so I assume it’s not a problem now anymore.

But it was a big problem where Linux laptops drained batteries much faster because they were using the GPUs at max capacity at all times.

What I’m saying is that the efficiency of Linux depends on access to hardware features, and that might depend on the vendors of the drivers.

Also, like it or not, if there’s one thing I envy about Mac is its power efficiency. They usually last really long on one charge.

His idea is that it’s faster to read that short string once you learn how to read it. But then you need to learn how to read it.

In my experience, every time I thought of something clever like this, I’ll almost always regret it a month later when I revisit the code.

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.

I almost pulled my hair out when I read that section. One is super obvious without any prior experience with the code. The other is an obscure abomination only he can understand. He’s obviously super proud of his abomination and thinks it’s a prime example of “clean code”.

Imo, if a method require the caller to do error handling, then that should be part of the return value. For example, use optional or either. Exceptions shouldn’t be part of any expected control flow (like file not found). Exceptions is an emergency panic button.

Yeah, that’s an argument of semantics. I agree with you.

What I believe is that functions should do exactly what they advertise. If they do the things they’re supposed to do, but also do other things they’re not supposed to do, then they’re not minimal.

But I feel like Uncle Bob is leaning more towards that if a task requires 100 different operations, then that should be split into 100 different functions. One operation is one thing. Maybe not exactly, but that’s kind of vibes I get from his examples.

why comments shouldn’t explain how the code works

I categorize this as one of the better points of the book.

functions should do one thing

I kinda disagree with him on this point. I wouldn’t necessarily limit to one thing, but I think functions should preferably be minimal.

Throughout his examples he’s also using ideas like how functions should only be 3 lines long, preferably have no arguments, and also no return values.

This style of coding leads to programs that are nightmarish to work with. The relevant code you’re looking for might be 10 layers deep of function calls, but you don’t know where. You’re just jumping between functions that does barely nothing until you find the thing you’re looking for, and then you need to figure out how everything is connected together.

I prefer when things are flatter. This generally leads to more maintainable code as it’s immediately obvious what the code is doing and how everything is connected.

I think his book is the equivalent of a cleaning guide where all the steps are just to sweep all the mess under the carpet. It looks cleaner, but it’s not clean.

I genuinely think his book is rubbish. I agree with some of his points. Most of the good points are common sense. For the most part I heavily disagree with the book.

Throughout the book he has examples of programs where he shows before and after he applies “clean code”, and in almost all examples it was better how it was before.

I can write a lot about why I don’t like his book. He doesn’t make many compelling arguments. It’s mostly based on what he feels is good. He often contradicts himself as well. If I remember correctly, he has a section about how side effects are bad. I agree with him on this part. Shortly after, he proudly shows an example of “clean” program - and it’s littered with awful side effects!

He also has this weird obsession of hiding the logic of the program. 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.

I can go on and on. I hate this book with a passion.

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.

He realized he couldn’t polish a turd.

Well, that as well, but it’s an also bit tricky to safely check if a number is even because JavaScript uses floats for numbers.