Comment by sqeaky | Hacker News Reader

Comment by sqeaky | Hacker News Reader

Parent Full thread

There were no real examples of when long functions helped. I can come up with 30 or examples of long functions being bad in the codebase I am working in now.

I stopped reading about halfway through as the contrived DRY twitter post. I did search the article for "test" and a few other keywords and found more flowery words without substance.

All the systems I have seen with long functions have had more bugs and greater difficulty to test. All the systems lacking DRYness have invariably had bugs because things weren't updated in all the places they needed to be. I have seen a clear correlation. I know that correlation is not causation, but the mechanism is simple and easy to understand: Long functions have more places for bugs to hide. The mechanism for dRY to help is equally simple:DRY code means fewer things need to be changed to fully cause a correct change. Both of these reduce the place for bugs to exist and my experience matches that.

I understand that my experience is that of only 1 person, but I have held 9 different software development contracts in the last decade and seen the full range of long to short functions and I have seen DRY and non-DRY code. This pattern has followed into open source code I have inspected. If I am wrong it will take strong concrete examples of DRY or short functions hurting, and I mean links to repos like github.

Author of the article here.

That's primarily the reason why there are no "concrete examples", because one person's concrete example is another person's definition of contrived. Splitting hairs over some toy example wasn't something I thought would buttress the ideas presented, though I can imagine why some might need that scaffolding to follow along.

Re resting - here are some points the article makes about how smaller functions can in some cases hurt testing:

1) "Furthermore, when the dependencies aren’t explicit, testing becomes a lot more complicated into the bargain, what with the overhead of setting up and tearing down state before every individual test targeting the itsy-bitsy little functions can be run."

Disambiguating this for you, one of the myths of smaller functions is that they are easier to test. The article makes the claim that this isn't always true, because many who wax lyrical about the beauty of smaller functions also champion for fewer arguments to be passed to the function. The book Clean Code very explicitly states this (read the book, not as a how to guide but as a cautionary tale), and many a time what I've seen happen in the wild (especially in Ruby) is that programmers who like small functions and don't like making deps explicit - which then means the code (and ergo tests) rely on setting up shared global state.

Of course one can write smaller funcs with fewer args and not do this, but that's not the point here. The main argument is that making functions smaller doesn't always make it easier to test.

The article also does provide two examples when having the smallest possible function does help in testing. I'm not going to rehash those arguments again here.

I have never read clean code and bringing it up as an argument against me and my points is a straw man. I don't think you meant for that though. Most of my knowledge was hard earned from a couple of decades of cleaning up disgusting long functions.

As for testing it is trivial to create examples of larger functions that cannot be tested each line of code introduces another possible thing that gets in the way of testing. I provided a contrived example (which is better than no example). The summary of it was that if a function creates connection to an external resource, uses it, the disconnects there is no way to test that function. Simply breaking it into three functions allows testing of the logic that uses the resource. Adding parameters that allows the resource or resource creator to be passed in allow testing of all three functions.

By skipping examples because someone will complain about how contrived it seems is to throw the baby out with the bathwater. As it stands your point is not falsifiable because it is possible for people on your side to just say "that's not a good long function" just as if it weren't a true scotsman. With examples you can at least ignore people who complain about the contrivance of them just as most successful technical speakers at conventions do.

> The main argument is that making functions smaller doesn't always make it easier to test

Only a Sith argues in absolutes... Sorry, I had to.

Seriously though know one seriously argues that it "always" makes it better. It just makes it better such a preponderance of the time that arguing against is foolish. It is like arguing for reasonable uses of goto, they might exist, but we as an industry have moved onto better designs.

I don't think it's really a contest between 100 line functions and single line functions. It's more about 5 - 20 line functions and 1 - 2 line functions. I could come up with lots of examples where being able to see the entire scope of 10 lines of logic is clearer than breaking the same thing into 5 functions.

Reply on news.ycombinator.com