5 ms·
If it's done right, though, you shouldn't have to navigate around all the smaller 5 line functions, at least not unless you're debugging. Each of the submethods
by potatoyogurt 10y ago
If it's done right, though, you shouldn't have to navigate around all the smaller 5 line functions, at least not unless you're debugging. Each of the submethods should clearly describe what it does, and do that without any unexpected side-effects or implicit state changes. Effectively, what this does is raise the level of abstraction of the code, so that your 50-line function becomes a 10-line function, and you only need to read those 10 lines to understand what's going on. Sometimes when you're debugging, you might need to dip into these subfunctions, but when you do, you should be able to think through them as mostly independent units that just need to do what their name says they will do. This ideally limits the problem of having to load everything that your code is doing into your head all at once in order to reason through it. When you're just reading through the code normally, you should be able to gloss over the details of how the submethods work, just as you probably wouldn't feel compelled to dig into the internals of how a library call like Collections.sort works.
The problem is that method decomposition is not always done well, and when there is unexpected behavior or implicit state changes, it can make bad code even harder to navigate. I'd also rather read a well-written 50 line function than a poorly decomposed cluster of 10-line functions. With proper care, though, method decomposition is super helpful.
- 20years 10y ago"The problem is that method decomposition is not always done well" Yeah :(
- sbov 10y agoPart of the problem is that the abstraction of "a sorted list" will never change. But the abstraction of "twiddle my foobar" can change on a weekly basis based upon business needs. Because of this the abstractions we write will never be as strong or enduring as those found in the standard library.
- potatoyogurt 10y agoCertainly true, but that's not a reason to give up on creating those abstractions, like the post I was replying to was suggesting. It's a reason to be judicious about when it's appropriate to create these abstractions, and in particular about when they should be shared. An abstraction that's used in just one or two places is still really easy to change. A bad abstraction used in a dozen places is a pain the ass to clean up. It's not an easy problem, and it ultimately takes some combination of experience and careful mentoring to learn to identify good and bad abstractions before they're built.
- sheepmullet 10y agoThat's the theory. In practice it is difficult to get the right level of abstraction. This is why writing a good library often takes 3x as much effort as writing the equivalent application code.
- tigershark 10y agoThis only means that you are not putting enough effort when writing your application code compared to the library. So you are basically adding technical debt to your application. Apart from a deadline that will make the project fail if it is missed I don't see any rational reason to add technical debt. And also in that case you must plan some time to remove the technical debt that you just introduced, and better sooner than later. So writing a library is not harder than writing a good application. It is certainly harder than writing quickly a mess of hacks that become an application.
- sheepmullet 10y agoSoftware engineering is all about tradeoffs. Since libraries have different use cases and characteristics than normal app code they can and should be treated differently. A 10% cognitive cost for code that is used by thousands of developers is a very high price to pay for an initial 3x speed boost to one developer. A 10% cognitive cost for code that needs to be understood 3-10x before it effectively expires (like most app code) is a great tradeoff for a 3x initial speed boost. I'll get my app in my customers hands in 3 months, wear a little "tech debt" on the dev side, and get crucial feedback. You can take 9 months to deliver a functionally equivalent app with slightly better internals.