On: What I learned in 2017 writing Go

[jeremiep]

Having a lot of single-use functions, even if properly named, still splits the context in that many pieces.

For some cases that results in more confusing code.

[vram22 → jeremiep]

I partly agree with acangiano and partly with you. On the whole, I tend to agree more with him, with this proviso: don't just name the functions well, name their parameters well too. That can make the overall program easier to understand, and we can still get the benefit of modularity and black boxes, while not creating more confusion. YMMV, of course.

[jeremiep → vram22]

I agree about modularity and encapsulation being important.

Usually I try to weight the overhead of having more function prototypes to track, indirections in the main function and whatnot versus the overhead of having it all inlined.

A lot of things become more evident as you inline one-use functions, because the whole context is now local.

[vram22 → jeremiep]

Yes, it's a tradeoff.

Interesting, your comment reminded me of inline functions in C++ and C99; not the same thing (or at least goal) as what we were discussing, but closely related:

https://en.wikipedia.org/wiki/Inline_function

[krylon → jeremiep]

I agree with you. Sometimes a single long-ish function is preferrable to a flock of shorter ones.

Still, I think the GP has a point - clear naming is very important, regardless of one's attitude towards function size. ;-)