I agree strongly with the main thrust of this article, but it doesn't support the "Loss of Locality" prong of the argument very well. > when reading through th

I agree strongly with the main thrust of this article, but it doesn't support the "Loss of Locality" prong of the argument very well. > when reading through the original caller, it is less clear what the code does In my experience it is usually clearer, if the function has an even remotely appropriate name. And unless you are coding with notepad.exe, toggling between caller and callee is pretty trivial. > When you move this code to a function as a part of a straightforward DRY refactoring, this means that now a function is mutating its parameters. Whether that matters depends a lot on the language. And anyway it seems like the main problem in code like that is that the function is inappropriately mutating state outside of itself in a surprising way, which might be a problem separate from dryness. "Loss of Locality" does strike me as reasonable argument against code that is too dehydrated though. Maybe somebody else can make some better supporting claims for it?