Small functions considered harmful • Hacker News Board

Re: Small functions considered harmful

#111

Post by whack » Fri, Aug 11, 2017, 10:35 PM UTC

copyconstruct wrote: post #108

whack wrote: post #105

Earlier quoted context omitted.

Hi. I'm not sure you actually bothered to understand my comment, because it's making 2 main points, which you have glossed over. 1st: The importance of concrete examples in illustrating your point. Sure, we can all think of and agree on extreme examples of short-functions or long-functions which are bad, but what about more realistic examples. In Clean Code, Robert Martin presents many realistic and reasonable code s…

>At my recent companies, I've even seen senior developers, people with fancy degrees and 200k+ salaries, write code that's horrendously hard to understand and maintain, because it's endlessly duplicated and squashed into a single long function. Ever wondered that they might be senior and commanding those salaries because they think and program a certain way? Have you ever discussed this with them? Many senior develop…

We're going far off into a tangent but to answer your question:

- the code in question constantly produced production bugs

- the code in question was extremely hard to debug when said production bugs surfaced

- everyone complained about that code being problematic, including other more senior engineers with 300k+ salaries

- all the above problems went away and everyone was pleased when I broke it up into smaller pieces

Re: Small functions considered harmful

#112

Post by joevandyk » Fri, Aug 11, 2017, 11:21 PM UTC

I've never been served wrong by constantly asking these questions:

1. How hard is this code to change?

2. How hard is this code to delete?

3. How hard is this code to test?

Code that is hard to change, delete, and test is bad. Code that is easy to change, easy to delete, and easy to test is good.

(Note: you can't easily change code if you can't understand it)

Long vs short functions don't really matter. Objects vs functions don't really matter. It doesn't matter if you use or don't use a ton of abstractions if they are easy to delete and change.

Re: Small functions considered harmful

#113

Post by zmmmmm » Sat, Aug 12, 2017, 12:02 AM UTC

novembermike wrote: post #84

IIRC the original concept of DRY wasn't "Don't Repeat Yourself" (that's the pithy version that's easy to remember but wrong). I think it was more like "A piece of knowledge should be found once in a code base", which isn't quite as easy to follow or remember but cuts to the issue more deeply. The problem isn't superficial duplication. I might do a .map(x->x*2) in multiple places, but if they represent different piece…

Nicely put. The problem with DRY is it is expressed in term of "repeating" so it suggests that code repetition is the problem. The flip side of achieving DRY is breaking isolation between two pieces of code. That's a downside - so DRY is a tradeoff, not a simple one sided win.

The real questions are things like "Is it likely if I change logic A, that B will also need to change in the same way?" and "Is it likely that if there's a bug in B, that would also be a bug in A?". If those things aren't true, you are shooting yourself in the foot because you will certainly be going in and changing A and B to maintain them and now every time you do that for one you are at risk of breaking the other.

DRY is usually right, but it definitely comes at a cost.

Re: Small functions considered harmful

#114

Post by zmmmmm » Sat, Aug 12, 2017, 12:06 AM UTC

sqeaky wrote: post #90

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…

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.

Re: Small functions considered harmful

#115

Post by mannykannot » Sat, Aug 12, 2017, 2:52 AM UTC

jacalata wrote: post #47

mannykannot wrote: post #24

Earlier quoted context omitted.

Most of the arguments in the article are agnostic to the size metric - offhand, I cannot think of any claim that is invalidated by changing to your measure. Furthermore, it is the proponents of short functions quoted in the article who are using line count as a metric, so it is not as if the author of this article has created a straw man by choosing a misleading metric.

Most of the arguments in the article seem agnostic to the size of the function altogether, which is hilariously ironic given the complaint about the "long functions are bad" example at the start of the book.

Most of the arguments concern the side-effects of splitting a given unit of work into a lot of functions, which is an inevitable consequence of the strategy being deprecated.

Re: Small functions considered harmful

#116

Post by theonething » Sat, Aug 12, 2017, 6:58 AM UTC

Sergesosio wrote: post #4

Functions exist to prevent code duplication not for commenting code, that's what comments are for.

I believe most rubyists would disagree with you.

I had a ruby loving coworker that made you feel like a moral failure if you commented your code instead of making it 'self-commenting'

Re: Small functions considered harmful

#117

Post by jacobush » Sat, Aug 12, 2017, 9:34 AM UTC

jdmichal wrote: post #72

whack wrote: post #25

During my earlier years, I would get into all types of dogmatic debates, such as "DRY-considered-harmful" or "small-functions-considered-harmful" . With experience, I've realized that such abstract debates are generally pointless. Any principal can lead to bad results when taken to an extreme, or badly implemented. Thus leading to people declaring that-principal-considered-harmful , swinging the pendulum to the oppos…

I think it's more likely that your "great programmers" simply understand the difference between the same functionality and accidentally similar functionality. The latter is where you have two use cases that are very similar, so you spend all this time deduplicating. Then one of the use cases changes... The correct response would be to duplicate the code again, because the two use cases are no longer similar. In reali…

Thank you for putting that into words, and rather few too. I have only felt that anti-pattern before, not had words for it. Does it have a name? If not, we should give it a name!

Re: Small functions considered harmful

#118

Post by laythea » Sun, Aug 13, 2017, 12:29 PM UTC

sqeaky wrote: post #93

laythea wrote: post #43

Function borders should be drawn by defining abstractions, not by counting lines of code. Sometimes, the most useful abstractions involve large functions.

Do you have examples?

The first one that comes to mind is main().

Re: Small functions considered harmful

#119

Post by sqeaky » Mon, Aug 14, 2017, 4:33 PM UTC

alkonaut wrote: post #101

sqeaky wrote: post #96

Earlier quoted context omitted.

There are several advantages you are disregarding. Functions have names and you get to name the code in a way that shouldn't expire the way comments can. In most languages separate functions create separate scopes. This prevent incidental use of temporaries from one section into another. Having a smaller scope to look at means that refactoring or changes to new business requirements can have a smaller place for side…

> Functions have names and you get to name the code in a way that shouldn't expire the way comments can. Sure that's a benefit, but often times I think the scrolling is a downside that is underrated. The code being right in front of you has huge value. > In most languages separate functions create separate scopes. This prevent incidental use of temporaries from one section into anothe Right. Thought I mentioned that.…

> but often times I think the scrolling is a downside that is underrated

What editor can't take you directly to a defined symbol, even ones in other files, nowadays?

As for API design, all classes and functions implicitly become APIs for more abstract code that calls it. Give any surviving piece of enough time and eventually one part of the code with depend on things provides by what logically seems like entirely different parts of the code. At some the team will wonder why these aren't separate libraries (or gems, pips, rocks, packages or whatever), and the API will be whatever the original classes and function were. And if those things were well encapsulate that process might be easy.

This is why least responsibility, DRY and the smallest functions possible are important. Eventually everything will be part of an unbroken stack connecting your users to a CPU and to fix problems in the middle you need simplicity.

Re: Small functions considered harmful

#120

Post by sqeaky » Mon, Aug 14, 2017, 4:45 PM UTC

copyconstruct wrote: post #107

sqeaky wrote: post #90

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…

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 small…

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.