3 ms·
I think this depends on person. There are two levels of reading code, one is getting a rough idea of how the code flows and works, the other is to check all the
by cttet 4y ago
I think this depends on person. There are two levels of reading code, one is getting a rough idea of how the code flows and works, the other is to check all the details of the code. Some people are better at the prior and some are better at later.
What this refactoring essentially do is to segment code in natural language blocks. For people who process things in natural language concept blocks this makes it easier to get the general idea of how the function works at a glance and diving in the implementation of the inner functions later.
This will of course introduce the overhead that you have mentioned that will increase the time for you to process the detailed flow of code. But as far as I can see it is only an overhead and by spending some time (or smart IDE or a pencil) there will not be a fundamental problem.
For people that are good at reading raw code without the help of concept-based segmentation, they may not experience the benefit but only the overhead.
- kamray23 4y agoYeah, this refactoring is dubious but I think it's still correct. "The successful response with `body`" is a lot simpler in my head to comprehend than `{:ok, body}`. There is little to no need to actually know what is being sent, if the types align it is correct. What's actually being sent can then be checked separately in total isolation to be correct. 7±3 things, that's the usual rule for how many variables you can track. Make it any more complex and you'll run into issues with comprehension and by extension with hidden bugs.