3 ms·
I have pretty mixed feelings about this. Personally I find it much easier to debug code that: 1) fits entirely on my screen and 2) doesn't involve much state
by bloaf 4y ago
I have pretty mixed feelings about this. Personally I find it much easier to debug code that:
1) fits entirely on my screen and
2) doesn't involve much state modification
Every intermediate variable is a chance for me to miss some modification (e.g. it was passed to a func that modifies its arguments) and consequently misunderstand what is happening.
I've been experimenting in Python with the function chaining style of coding enabled by the toolz library. So while not at all idiomatic, the example in the original article would come out as something like this:
https://gist.github.com/ZeroBomb/8ac470b1d4b02c11f2873c5d4e0512a1 https://gist.github.com/ZeroBomb/8ac470b1d4b02c11f2873c5d4e0...
I would say that function-chaining this example would constitute over-engineering, but I have found that writing in this style has really helped me express pretty complex function composition in a way that is still concise without using a bunch of intermediate variables.
- readthenotes1 4y agoDo you really write a very long comment after every function call? And have you looked at code that's over a year old and modified by other people to see how poorly those comments now match the code?
- bloaf 4y agoNo. I did that for people having a first exposure to this non-idiomatic currying/function chaining. In actual code I would have put most of those on one line.
- strager 4y agoHow do you debug that code?
- bloaf 4y agoThis particular case is special because it uses 100% library functions. Typically you're composing your own functions, so you just... put breakpoints in your functions. If you want logging, I've added an example of how to auto-log the composed functions to the gist.