4 ms·
If you're calling those functions once each in a particular order then I can't possibly figure out what that does for you that whitespace and a few comments wou
by BigJono 5y ago
If you're calling those functions once each in a particular order then I can't possibly figure out what that does for you that whitespace and a few comments wouldn't. How does turning 100 lines of code into 120 and shuffling it out of execution order possibly make it easier to read?
- nojokes 5y agoA recommended reading https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599 https://www.amazon.com/Refactoring-Improving-Existing-Addiso...
- throwawaythekey 5y agoI coded this way for a while and found it makes the code easier to read and easier to reason about. Instead of your function being func foo() { // do A.1 // do A.2 // do B.1 // do B.2 // etc... } It becomes func foo() { // do A // do B // etc... // func A()... // func B()... } When the func is doing something fairly complicated the savings can really add up. It also makes expressing some concurrency patterns easier (parallel, series etc...), I used to do this a lot back in the async.js days. The main downside seems to be less elegant automated testing from all the internal state.
- josephg 5y agoNo; I wouldn't do it if I was just calling them once each in a particular order. And I don't often use this trick for simple functions. But sometimes long functions have repeated behaviour. For example, in this case I needed to do two recursive tree walks inside this function, so each walk was expressed as an inner function which recursively called itself, and each is called once from the top level method: https://github.com/ottypes/json1/blob/05ef789cc697888802e7867f0e06d64b2b0471ba/lib/json1.ts#L422-L579 https://github.com/ottypes/json1/blob/05ef789cc697888802e786... I don't do it like this often though. The code in this file is easily the most complex code I've written in nearly 3 decades of programming. Here my ability to read and edit the code is easily the most important factor. I think this form makes the core algorithm more clear than any other way I could factor this code. I considered smearing this internal logic out over several top level methods, but I doubt that would be any easier to read.