4 ms·

> For what it's worth, my take on it is that you should extract whatever bits of pure functions you can find in the 1000-line ones. Do these bits of pure funct

> For what it's worth, my take on it is that you should extract whatever bits of pure functions you can find in the 1000-line ones. Do these bits of pure functions appear anywhere else in the code? If so, sure, I happily pull them out into their own functions. If not, I will leave them exactly where they are. It's easier to read a laundry list than to look up many different parts in isolation without context. As for testability: If some bit of code only appears in that one long laundry-list function, what do I gain by testing it outside of that context?

Dudeman112 4y ago
That's acceptable if you have really good reasons to assume the requirements won't change next week, which happens almost never. 1000x1 lines of code all at once have a lot of space for hidden non-obvious interactions. Maybe it won't have that, but I haven't ever encountered it. Making it 10x100 lines of code won't necessarily make it better, but at least it should isolate chunks that can be understood with little effort. Having to understand 1000 lines of code before being reasonably certain you can make a change is far harder than understanding some 20-50 lines.
- hombre_fatal 4y ago
  On the other hand, since you don’t know future requirements, it’s easier to refactor/abstract unabstracted code than to refactor/reabstract already-/wrongly-abstracted code. Function extraction adds indirection that doesn’t necessarily pay its own rent. It’s not free.
- usrbinbash 4y ago
  If requirements change next week, I change the code ... next week. I don't change code now to be prepared for something that may or may not happen. > but at least it should isolate chunks that can be understood with little effort. The chunks are easier to understand. But the laundry list function that calls them isn't because it's logic is now spread over 10 different functions.
  - Dudeman112 4y ago
    >The chunks are easier to understand. But the laundry list function that calls them isn't because it's logic is now spread over 10 different functions That's... the point of abstractions and programming languages. At work you don't regularly care how System.out.println() is implemented, do you? If we follow your way of thinking through all we would have would be binary. Maybe assembly. The whole point of having programming languages and functions is having high level descriptions of what it is doing without having to worry about the implementation unless we have to. Now, maybe the 1000 lines of code is actually ultra specific and has no bearing at all on everything else, but that's not really common. Could also be that the 1000 lines are more data structure than code. There is a level of abstraction that's conducive to understanding stuff. Going at higher level costs obscuring implementation details, going at lower level costs making it hard to understand what it does. One thousand lines of code is probably way too low level. Chunking those 1000 lines into smaller abstractions is already what your brain will do when trying to make sense of it (because the cache is small for abstractions and concepts that aren't already internalized)

Dudeman112 4y ago

That's acceptable if you have really good reasons to assume the requirements won't change next week, which happens almost never. 1000x1 lines of code all at once have a lot of space for hidden non-obvious interactions. Maybe it won't have that, but I haven't ever encountered it. Making it 10x100 lines of code won't necessarily make it better, but at least it should isolate chunks that can be understood with little effort. Having to understand 1000 lines of code before being reasonably certain you can make a change is far harder than understanding some 20-50 lines.

hombre_fatal 4y ago
On the other hand, since you don’t know future requirements, it’s easier to refactor/abstract unabstracted code than to refactor/reabstract already-/wrongly-abstracted code. Function extraction adds indirection that doesn’t necessarily pay its own rent. It’s not free.
usrbinbash 4y ago
If requirements change next week, I change the code ... next week. I don't change code now to be prepared for something that may or may not happen. > but at least it should isolate chunks that can be understood with little effort. The chunks are easier to understand. But the laundry list function that calls them isn't because it's logic is now spread over 10 different functions.
- Dudeman112 4y ago
  >The chunks are easier to understand. But the laundry list function that calls them isn't because it's logic is now spread over 10 different functions That's... the point of abstractions and programming languages. At work you don't regularly care how System.out.println() is implemented, do you? If we follow your way of thinking through all we would have would be binary. Maybe assembly. The whole point of having programming languages and functions is having high level descriptions of what it is doing without having to worry about the implementation unless we have to. Now, maybe the 1000 lines of code is actually ultra specific and has no bearing at all on everything else, but that's not really common. Could also be that the 1000 lines are more data structure than code. There is a level of abstraction that's conducive to understanding stuff. Going at higher level costs obscuring implementation details, going at lower level costs making it hard to understand what it does. One thousand lines of code is probably way too low level. Chunking those 1000 lines into smaller abstractions is already what your brain will do when trying to make sense of it (because the cache is small for abstractions and concepts that aren't already internalized)