3 ms·

I find a lot to agree with here. It's all very conceptually neat and (if you're lucky) easy to read from the top down, where you enter one function and read of

I find a lot to agree with here. It's all very conceptually neat and (if you're lucky) easy to read from the top down, where you enter one function and read off a list of other functions which are called in order. But then if you look into any of those other functions they also call more functions and so on, several levels deep. And when you have to debug someone else's code because the data after function 15 of 17 isn't quite right, and you have to unpick all the places it's been passed through in slightly different versions and slightly different lists of parameters, it can be a nightmare. Same with my linter telling me to close a file within a few lines of opening it. Personally I'd rather keep all the file-munging code in one place rather than scatter it down a rabbithole of nested functions as an exciting Alice In Wonderland story for future developers. I try to come to a compromise on these things when working in a team, though...

deleted 9y ago
[deleted]
wiz21c 9y ago
This is a very valuable comment. Indeed pushing the abstraction to small functions actually remove abstraction in the "system of function". So there is a tension. what I find super interesting in your comment is that you solve this as a team. So, my point is, this demonstrates (a bit) the fact that coding is also a social activity. Of course, anything a team produces is a reflection of the team itself. But here you pinpoint the fact that you adapt your solution to the team as well as to the problem itself (anyone else would have said "I choose this solution because it's the best for the problem") I like that :-)
jacalata 9y ago
Wouldn't the compromise be unit testing?
- geezerjay 9y ago
  > Wouldn't the compromise be unit testing? I agree. Unit testing is done to ensure that all components work exactly as they are expected to work. If any component fails to work but developers only notice it "because the data after function 15 of 17 isn't quite right" then it appears that something is very wrong with the way those units are being tested.
kazagistar 9y ago
I tend to agree, but not with your particular example; the boundry between how you manage a resource and what you do with it seems like the perfect place to put an abstraction. The file mingling can be in one big function, but there are benefits to separating it from the open/close logic.

deleted 9y ago

[deleted]

wiz21c 9y ago

This is a very valuable comment. Indeed pushing the abstraction to small functions actually remove abstraction in the "system of function". So there is a tension. what I find super interesting in your comment is that you solve this as a team. So, my point is, this demonstrates (a bit) the fact that coding is also a social activity. Of course, anything a team produces is a reflection of the team itself. But here you pinpoint the fact that you adapt your solution to the team as well as to the problem itself (anyone else would have said "I choose this solution because it's the best for the problem") I like that :-)

jacalata 9y ago

Wouldn't the compromise be unit testing?

geezerjay 9y ago
> Wouldn't the compromise be unit testing? I agree. Unit testing is done to ensure that all components work exactly as they are expected to work. If any component fails to work but developers only notice it "because the data after function 15 of 17 isn't quite right" then it appears that something is very wrong with the way those units are being tested.

kazagistar 9y ago

I tend to agree, but not with your particular example; the boundry between how you manage a resource and what you do with it seems like the perfect place to put an abstraction. The file mingling can be in one big function, but there are benefits to separating it from the open/close logic.