101–110 of 192 posts
Make it work, then make it "clean" (that is, readable and maintainable); then make it fast, and only if measurement indicates that it matters.
Yes, a toy problem only needs a simple implementation. This is a straw man. And I don't even like Robert Martin's Clean Code, but the author is not addressing where this style actually provides benefits. When you're updating 23 if-statements because you had to add support for some new business workflow, you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had t…
This is the author's gripe, though. You're sacrificing end user experience for developer ergonomics.
No. You may be sacrificing end user experience, but it's not guaranteed. You have to examine the system under development to determine which style is appropriate.
If you actually have to process huge numbers of these objects, then yes. But if you don't, if whatever the actual real-world object is trickles in at 10 per second, do you need to worry about performance and cache misses here? You're already going to suffer from cache misses because the processing rate is so low.
So you get to make an engineering choice based on circumstances. If you need high-throughput, use a design that satisfies that requirement but maybe forfeits flexibility and maintainability. If you don't, then you can lean towards a design that forgoes a bit of performance in favor of flexibility and maintainability.
Use your judgement, don't follow any rule blindly whether it comes from Muratori or Martin.
Earlier quoted context omitted.
> I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.
Sadly it is serious and in production code. (I left there 15 years ago, I suspect it isn't in production anymore) Worse, it was a giant switch, and the target system didn't have enough memory for all the code so there were different builds and the user would select which to load. There was code like case foo: doSomething(); #ifdef build_two doSomethingElse(); break; case bar: SomeThing(); #endif MoreThings(); break;…
Earlier quoted context omitted.
> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. It's very hard to make a function you need to scroll back and forth to understand readable. Break it into smaller ideas that are more easily reasoned about. We love to think we are too clever, but we are not…
I think the rule that "functions should be small enough that they should be easily reasoned about" is a reasonable rule, and it makes sense to follow it 95% of the time. "Functions should be 5 lines or less" is a measure that approximates that rule, but isn't exactly the same thing - I hope you agree we could both come up with 4 line functions that are impossibly complex or 6 line functions that are easily reasoned a…
This can’t really be a serious guideline unless you are writing APL, in which 5 lines can already be daunting to grasp. This guidance depends on the language. For Python, once you get over 50 lines it starts to look like you don’t actually know what you are doing anymore.
Earlier quoted context omitted.
Sadly it is serious and in production code. (I left there 15 years ago, I suspect it isn't in production anymore) Worse, it was a giant switch, and the target system didn't have enough memory for all the code so there were different builds and the user would select which to load. There was code like case foo: doSomething(); #ifdef build_two doSomethingElse(); break; case bar: SomeThing(); #endif MoreThings(); break;…
I’m not sure the author knew what was happening. It seems like it worked like this and they left it at that.
This is just bloody stupid. If you care about performance, you don't use OOP, you don't use if/else, you don't use switch{case}, what you do is you write the hot parts in assembler. If you aren't writing it in assembler, you're writing slow code. But that code is still not optimised until you've implemented it in an ASIC.
Depends in part in how good you are at writing assembler.
I stopped reading as soon as I saw the shape class. This example (along with the proverbial animal) has done a lot of harm to OOP and programming. You need base classes (which are not always the right answer, but when they are) to be based on the abstract concept you need to model not something real that is easy to understand when someone isn't an expert in your domain.
https://www.youtube.com/watch?v=zHiWqnTWsn4
1:00:00 - Open/closed principle and 1:13:52 - Liskov substitution principle.
Both are given in terms of Shape, but it's to paint the picture that things are more complicated than you thought, even with something that should have been as simple as shapes. (As opposed to "shapes are easy, just model the world like that and it will be easy too")
Earlier quoted context omitted.
Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather…
> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. It's very hard to make a function you need to scroll back and forth to understand readable. Break it into smaller ideas that are more easily reasoned about. We love to think we are too clever, but we are not…
Here’s a 150 line long function I wrote which I think is quite beautiful:
https://github.com/josephg/diamond-types/blob/e143890a596aaf...
This function traverses a DAG given 2 points in the dag, A and B. It breaks the dag into 4 regions - the nodes which are (transitively) only in the parent subgraph of A, B, in both or - implicitly - in neither. It runs in O(n log n) time.
How would you improve this function? It could use a better doc comment. But do you honestly think it would be better if it were broken into a lot of small functions, each called once? How would you do it?
I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…
> but harmful to late-stage developers who adopt it as dogma. Even Robert Martin, very often in his videos and blogs, espouses "engineering judgment" and is quite fine abandoning advice in his book when the situation calls for it. If performance is important and clean code is impacting it, he won't object to your breaking the rules. It's mostly with his TDD evangelism that he goes (a little) crazy.
I really like that he brings attention to the idea that code can be beautiful. But judging by his examples, he just seems to have no idea how to actually write beautiful software himself.
I wish he went off and learned some functional programming. Haskell, Erlang, Clojure, F#. Something like that. Really go deep. If you want to know what really beautiful software looks like, that’s the place. Those communities know beauty.
Yes, a toy problem only needs a simple implementation. This is a straw man. And I don't even like Robert Martin's Clean Code, but the author is not addressing where this style actually provides benefits. When you're updating 23 if-statements because you had to add support for some new business workflow, you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had t…
This is the author's gripe, though. You're sacrificing end user experience for developer ergonomics.
When working on large applications, by far the single most important factor in performance is having simple and understandable code.
Understandable but slow code can be fixed. Incomprehensible code can't, so it either stays slow or gets worked around with caching/async processing/etc.
If you want fast software, you should write the simplest thing that isn't obviously stupidly slow, then measure and see what parts you need to change. Occasionally you need to make pieces less readable to make them faster, but it's going to be 5% of the application, not the whole thing.