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

11–20 of 121 posts

Re: Small functions considered harmful

#11

Post by deckiedan »

I wrote something myself trying to figure out my thoughts about this a few years ago (note: I was sleep deprived when writing it...):

https://madprof.net/nerdy/refactoring-really/

There certainly has been a over-emphasis in some quarters on 'each function should only do one thing' and even 'most of my functions are only one or two lines long'. Possibly because it makes it easier to write tests for, and be certain you've covered all of the possible options. You just then end up writing 4 million tests.

It's all about clarity, I think, but different people find different things clearer in different situations.

Re: Small functions considered harmful

#12

Post by jstimpfle »

In a program, there's a lot to optimize for

    - minimize depth of call stack. It's easy to lose track in a deep call stack.
    - minimize function overhead
        - names that have to be invented
        - function calls and arguments that have to be written (and read again).
        - many small functions: "ravioli code" where it's really hard to distinguish functions
          by their "function"
    - minimize/localize state
       - if it's easy to separate significant state into a function, do it.
         (Not making a statement about objects. They are long-lived and their
         state doesn't go away after the first call).
    - DRY
       - Multiple identical or similar code blocks are an opportunity to make
         a function. We can roughly categorize into essentially (conceptually)
         and accidentally similar code, and the latter case is not an indication
         for a new function.
    - obvious thread of control
       - simple code has the nice property that it's easy to understand by
         following or mapping out sequentially. By contrast, highly abstracted
         or callback-heavy code is hard to understand at a global level.
    - consistency
         - ... helps understanding, but can also cause an implementation to be
           5 or 10 times longer if applied dogmatically.
It's good to read all these articles ("avoid state", "avoid long functions", "avoid objects", "avoid functional programming", "avoid abstraction") and to deeply understand them. Which probably means making all the mistakes on one's own.

In the end it's important to know in which situations a particular style works well, and to not be dogmatic when choosing a style.

I would say a good program tends to have both large and small functions, and the large functions tend to be at the top of the abstraction stack.

Re: Small functions considered harmful

#14

Post by dotdi »

Aside from the clickbait-y title, I find it quite disturbing to base that whole piece on, what even the author describes as, problems in "codebases inherited from folks who’d internalized this idea to such an unholy extent".

Indeed, small functions can be bad if you completely and utterly overdo it. But wait, that's true of nearly everything else.

Re: Small functions considered harmful

#15

Post by throwanem »

Obsessive decomposition of the sort Fowler, for example, is cited preferring, very quickly becomes pathological - I suspect that the codebase Fowler describes in that tweet, to the developer as yet unfamiliar with it, reads like one of those old IBM field engineer manuals where a giant circuit diagram is spread across 800 letter-size pages, all bordered with dozens of numbered arrows each referencing the page on which a given trace continues.

But I sort of feel like Sridharan throws the baby out with the bathwater, too. I mean, in the CRUD example, carefully chosen abstractions make the code easier, not harder, to read - if I'm working to comprehend how the application handles UI state changes, I don't want to have that effort complicated by a bunch of user-creation-related database interaction; I'd much rather that be in a method call so I can deal with it it when I care about user creation, and ignore it when I don't. Same for email messaging and event log injection.

And I have to say that my experience gives me to think the idea of preferring duplication over abstraction is just completely, wildly off base. I mean, sure - any given abstraction is likely to change over time as feature requests and bug reports come in. That's just the job. But if the stuff that needs to change is abstracted, it only has to change in one place. If it's not abstracted, then it has to change in N places across the entire application, not all of which are guaranteed to be easy to find - after all, you probably don't have distinctive method or function names. Hope you've got good tests! Except you don't. Or maybe you do - I never have, at any point in my career where I've worked with a codebase in which copy-pasted code was prevalent, because such a codebase is a sign of an engineering culture that's far too weak to support investment in automated testing.

Re: Small functions considered harmful

#17

Post by calafrax »

This discussion is predicated on the concept that function size is calculated by the number of lines which is completely wrong.

function size (function complexity actually) is measured primarily by indent levels not length and when there are multiple indent levels with nested branches and loops this is when you are supposed to create functions. length is not really an issue in most cases.

Re: Small functions considered harmful

#18

Post by calafrax »

exergy wrote: post #7
jghn wrote: post #6

Earlier quoted context omitted.

Define "a thing". This is the crux of all of these debates, IMO. Most people agree a function should do one thing, people tend to disagree on the granularity of things.

Which is precisely why debates like these can occur in the first place, it's not an exact science. Which is also why the parent started with "It depends".

yes it is actually. if your function has a logical branch then it is doing more than one thing. if your function has a logical branch within a logical branch then it is doing exponentially more things and this complexity continues to grow exponentially.

therefore, if you have a logical branch you ask yourself: does it make sense to create a function here? the answer may be yes or no. if you create a nested logical branch you ask yourself: does it make sense to create a function here? the answer still may be yes or no but the weight of the evidence for yes has increased exponentially.

Re: Small functions considered harmful

#20

Post by Denzel »

chinhodado wrote: post #10
moxious wrote: post #3

Shortness in a function is correlated with quality in design, but it doesn't cause quality in the design. When we simply follow formulaic advice (keep all of your functions short) we lose sight of the wisdom behind why this was wanted in the first place. The goal is to develop the wisdom, that makes you a great engineer, not to "follow all of the rules"

> The goal is to develop the wisdom, that makes you a great engineer, not to "follow all of the rules" This is why books like Clean Code can be harmful. It can be extremely dogmatic if blindly followed, which is very common unfortunately.

Clean Code can be harmful? Or the person dogmatically applying the advice?

Martin warns against such blind dogmatism. He even goes so far as to explain the thought process behind most of his recommendations so that one may consider whether the rule applies or not.

On balance, Clean Code does far more good than it does bad.

I have yet to see these dogmatic Clean Coders blindly applying Martin's advice. Not in industry and certainly not in open-source. It's painful to work with most OSS.

Eugene Schwartz, one of The Godfather's of advertising, when asked, "How long should an ad be?" liked to say... as long as you can hold the reader's interest.

Much like Martin would say when asked how long a function should be... as long as you're working at the same level of abstraction.

Post reply on HN