Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small functions considered harmful

medium.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: Small functions considered harmful

#91

Post by grey-area »

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…

Having short-functions and DRYness is indeed prone to abuse, but it still works as a general guideline

The author disagrees. She's saying people tend to use too much abstraction, so the DRY principle (not principal) is actively harmful as it encourages more of a bad thing. The trouble with abstraction is it hides things from view.

To make this concrete consider a codebase with lots of 1-10 line functions spread amongst lots of files, vs one with half the functions in half the files which are 10-20 lines instead. The work has to get done somewhere, and lots of shorter functions of just a few lines and keeping it dry (no repetition) tends to lead to lots of classes/files/modules which don't do much alone calling each other, making it much harder to reason about execution or read the code.

Rather than functions with just a few lines or with hundreds of lines, I imagine she's talking about functions 10-100 lines long on average, with exceptions where reasonable. There is a middle ground here where a function is more readable and crucially doesn't force you to jump around much to find out what work it does.

There's a good quote from Sandi Metz in the article: "duplication is far cheaper than the wrong abstraction"

Re: Small functions considered harmful

#92

Post by EpicEng »

grey-area wrote: post #91
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…

Having short-functions and DRYness is indeed prone to abuse, but it still works as a general guideline The author disagrees. She's saying people tend to use too much abstraction, so the DRY principle (not principal) is actively harmful as it encourages more of a bad thing. The trouble with abstraction is it hides things from view. To make this concrete consider a codebase with lots of 1-10 line functions spread among…

I work primarily on lower level components in biotech and I see this whenever I start to dig into the "Enterprise" code base. It takes me _far_ too much time to find the code that, you know... actually does something. While searching I'm just wading through file after file which contains nothing more than types and small wrappers around other small wrappers (around other small wrappers...) It drives me nuts. So much code and so little actually happening.

Re: Small functions considered harmful

#94

Post by sqeaky »

euroclydon wrote: post #48

If you want to have an easy time refactoring code later, forgo OO patterns that have properties and methods in the same class. Instead, make classes for your data, and make sure to give each class a deep clone method. Then, your logic goes in static functions that do not alter the input, but rather spit out new or cloned versions of the data in the output. Then you can reason and refactor at the method layer and not…

That seems a bit extreme compared to where many teams are at, but I can see how it could work.

How would you compare that to reducing the size of classes to bound where side effects can happen?

Re: Small functions considered harmful

#95

Post by sqeaky »

moocowtruck wrote: post #35

I feel like an article such as this should be full of code examples, just talking about this or that in which there are many dependent situations in which "it depends" just makes me get sleepy

Even the highest voted post here is commenting on the value of examples and lack of value in higher order discussion.

I must discard the post because everyone I have known professionally with similar opinions was grossly incompetent. Some strong examples would make it foolish for me to disregard this out of hand.

Re: Small functions considered harmful

#96

Post by sqeaky »

alkonaut wrote: post #34

one problem with the example of functions A() B() C() Called in sequence is that they smell of imperative code. A recipe of some kind, of steps performed in sequence. That kind of code, when it occurs, should probably just be performed in a single function. That is - until either A, B or C can be re-used by other code without creating an unnatural abstraction. If the steps as separate functions can be tested separate…

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 effects to occur.

I agree that testing each part on its isn't required, but if it becomes part of the public API and A is setup database connection and C is teardown Database connection and B is use the database connection then as one function B is really hard to test. Breaking it into three functions lets you write unit tests for at least B by mocking A and C.

Re: Small functions considered harmful

#97

Post by sqeaky »

imron wrote: post #57

For me, I generally try to break in to smaller parts any function where the logic extends over one screen in length. There are of course always exceptions to this, but having logic take up roughly a single screen size makes it easy to reason about.

I have a 4k screen at some point this pattern stops working.

Re: Small functions considered harmful

#98

Post by madmax96 »

EpicEng wrote: post #92
grey-area wrote: post #91

Earlier quoted context omitted.

Having short-functions and DRYness is indeed prone to abuse, but it still works as a general guideline The author disagrees. She's saying people tend to use too much abstraction, so the DRY principle (not principal) is actively harmful as it encourages more of a bad thing. The trouble with abstraction is it hides things from view. To make this concrete consider a codebase with lots of 1-10 line functions spread among…

I work primarily on lower level components in biotech and I see this whenever I start to dig into the "Enterprise" code base. It takes me _far_ too much time to find the code that, you know... actually does something. While searching I'm just wading through file after file which contains nothing more than types and small wrappers around other small wrappers (around other small wrappers...) It drives me nuts. So much…

But how much of that is small functions, and how much is just people blindly applying pattern after pattern while optimizing for business use-cases that are unlikely to ever emerge?

That doesn't mean the patterns are bad, it doesn't mean small functions are bad, it just means the person who implemented them lacked good judgement. Good judgement is somewhat subjective. Fortunately, we can combat this subjectivity by looking at what the long term $ of a decision (programmer time, onboarding time, resources used...), how a particular decision advances an organization's objectives, etc.

We need functionality, not code. That functionality exists to support (what should be) clearly defined interests and goals. "Right" code is code that serves the functionality, and therefore the goals, best.

Re: Small functions considered harmful

#99

Post by EpicEng »

madmax96 wrote: post #98
EpicEng wrote: post #92

Earlier quoted context omitted.

I work primarily on lower level components in biotech and I see this whenever I start to dig into the "Enterprise" code base. It takes me _far_ too much time to find the code that, you know... actually does something. While searching I'm just wading through file after file which contains nothing more than types and small wrappers around other small wrappers (around other small wrappers...) It drives me nuts. So much…

But how much of that is small functions, and how much is just people blindly applying pattern after pattern while optimizing for business use-cases that are unlikely to ever emerge? That doesn't mean the patterns are bad, it doesn't mean small functions are bad, it just means the person who implemented them lacked good judgement. Good judgement is somewhat subjective. Fortunately, we can combat this subjectivity by l…

It's the latter. Too much abstraction for no good reason because it's "what you do". I wasn't throwing out an opinion on the primary concern of the topic. In my experience, good devs write good code.

Re: Small functions considered harmful

#100

Post by copyconstruct »

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…

Author of the article here.

A few things. First, I'm not sure you actually bothered reading the article, because the conclusion very obviously states what you're suggesting here, in that:

"This post’s intention was neither to argue that DRY or small functions are inherently bad (even if the title disingenuously suggested so). Only that they aren’t inherently good either."

As for the lack of examples, I'd imagine most people can extrapolate and draw analogies from their long and storied programming careers of the sort they stake a claim to. If there's something you'd like explained in more detail, let me know and I can try cooking up a contrived example, but it will remain somewhat contrived all the same.

This article isn't for duplication either - as a matter of fact it's against absolutes and blanket generalizations like "Code smells if your functions are longer than 3 lines", which is something I often come across.

I think what you call "mediocre programmers" -- personally though, I'd like to be more charitable and think of this demographic as the average programmer or the vast majority of programmers -- are also the ones most likely to cargo cult a piece of advice that's sold as "programming wisdom". Any "advice" needs to be taken with a grain of salt. The article goes on to state how important this is, as well:

"As with most other things, “the ideal” lies somewhere in between. There is no one-size-fits-all happy medium. The “ideal” also varies depending on a vast number of factors — both programmatic and interpersonal — and the hallmark of good engineering is to be able to identify where in the spectrum this “ideal” lies for any given context, as well as to constantly reevaluate and recalibrate this ideal."

Post reply on HN