magic_lobster_party

  • 1 Post
  • 410 Comments
Joined 7 months ago
cake
Cake day: March 4th, 2024

help-circle


  • 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.







  • 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.








  • It depends on what type of programming you’re doing.

    But for OOP, my favorite patterns are composition over inheritance and dependency injection (with constructor injection). Once you know these two the rest will follow naturally, and your programs will turn more modular and easier to maintain.

    One common misconception about dependency injection is that you need a framework for it. That’s not the case. Frameworks only make some stuff more convenient, but you can do without it.

    Otherwise, I think the best way to learn is by doing. It’s easier to see why a pattern is important when you have first hand experience of how painful it is without it.

    Edit: Avoid the book “Clean Code”. That book has just done more harm than good in the world.