5 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. This would help testing and u

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. This would help testing and understanding. You can test and understand the parts independently, and only have to test the huge function in order to check that the parts are attached correctly. https://rhodesmill.org/brandon/talks/#hoist https://rhodesmill.org/brandon/talks/#hoist https://danuker.go.ro/the-grand-unified-theory-of-software-architecture.html https://danuker.go.ro/the-grand-unified-theory-of-software-a...

andi999 4y ago
Only if the pure function have a few parameters and do not need to carry the world.
- danuker 4y ago
  You can bundle the parameters into plain/pure/humble objects where it makes sense. https://khanlou.com/2014/12/pure-objects/ https://khanlou.com/2014/12/pure-objects/ http://xunitpatterns.com/Humble%20Object.html http://xunitpatterns.com/Humble%20Object.html
  - mannykannot 4y ago
    'Where it makes sense' is key - otherwise you are just stuffing the wiring behind the desk, adding to the difficulty of understanding it.
marginalia_nu 4y ago
This a bit of an aside, but I wonder if people would be less prone to advocate pure functions if they had a name that didn't sound like a paladin had come up with them. Would people as eagerly advocate rewriting code to break it into greasy functions?
- danuker 4y ago
  "Side-effect-free" would be a mouthful, and I don't know any other name that is both accurate and well-known.
  - marginalia_nu 4y ago
    Well pure is just as arbitrary as greasy, isn't it? Except one has positive connotations and the other has negative ones.
Verdex 4y ago
Well not necessarily just 'pure'. You also want unsurprising. For example imagine a pure function that takes a string and returns a string. The returned string has every character lower cased. Okay name it to_lower and move it out. But now imagine that it returns the complete text of Shakespeare if the input it 'bob' (why? customer requirement. their business literally falls apart if this doesn't happen). In this case you probably shouldn't pull it out into it's own thing because it's so specific (and weird) that you'll want it nearby it's use case (and not available for developers to accidentally use for the non Shakespeare uses). * yeah this is convoluted. There are better ways to factor such a function. However the point is that something can be 'pure' but still not a good candidate to be pulled out of context.
- dolni 4y ago
  > In this case you probably shouldn't pull it out into it's own thing because it's so specific (and weird) that you'll want it nearby it's use case (and not available for developers to accidentally use for the non Shakespeare uses). I guess it depends on how much this weird Shakespearean to_lower is used around the codebase. If there is one spot where it's used, I would probably factor out to_lower and add a special case check for "bob" in the business logic code (outside the scope of to_lower). If the Shakespearean to_lower gets used in various places it actually might make sense to be factored into its own function.
  - Verdex 4y ago
    * yeah this is convoluted. There are better ways to factor such a function. However the point is that something can be 'pure' but still not a good candidate to be pulled out of context.
usrbinbash 4y ago
> 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.
    - 4y ago

andi999 4y ago

Only if the pure function have a few parameters and do not need to carry the world.

danuker 4y ago
You can bundle the parameters into plain/pure/humble objects where it makes sense. https://khanlou.com/2014/12/pure-objects/ https://khanlou.com/2014/12/pure-objects/ http://xunitpatterns.com/Humble%20Object.html http://xunitpatterns.com/Humble%20Object.html
- mannykannot 4y ago
  'Where it makes sense' is key - otherwise you are just stuffing the wiring behind the desk, adding to the difficulty of understanding it.

marginalia_nu 4y ago

This a bit of an aside, but I wonder if people would be less prone to advocate pure functions if they had a name that didn't sound like a paladin had come up with them. Would people as eagerly advocate rewriting code to break it into greasy functions?

danuker 4y ago
"Side-effect-free" would be a mouthful, and I don't know any other name that is both accurate and well-known.
- marginalia_nu 4y ago
  Well pure is just as arbitrary as greasy, isn't it? Except one has positive connotations and the other has negative ones.

Verdex 4y ago

Well not necessarily just 'pure'. You also want unsurprising. For example imagine a pure function that takes a string and returns a string. The returned string has every character lower cased. Okay name it to_lower and move it out. But now imagine that it returns the complete text of Shakespeare if the input it 'bob' (why? customer requirement. their business literally falls apart if this doesn't happen). In this case you probably shouldn't pull it out into it's own thing because it's so specific (and weird) that you'll want it nearby it's use case (and not available for developers to accidentally use for the non Shakespeare uses). * yeah this is convoluted. There are better ways to factor such a function. However the point is that something can be 'pure' but still not a good candidate to be pulled out of context.

dolni 4y ago
> In this case you probably shouldn't pull it out into it's own thing because it's so specific (and weird) that you'll want it nearby it's use case (and not available for developers to accidentally use for the non Shakespeare uses). I guess it depends on how much this weird Shakespearean to_lower is used around the codebase. If there is one spot where it's used, I would probably factor out to_lower and add a special case check for "bob" in the business logic code (outside the scope of to_lower). If the Shakespearean to_lower gets used in various places it actually might make sense to be factored into its own function.
- Verdex 4y ago
  * yeah this is convoluted. There are better ways to factor such a function. However the point is that something can be 'pure' but still not a good candidate to be pulled out of context.

usrbinbash 4y ago

> 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.
  - 4y ago