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

51–60 of 121 posts

Re: Small functions considered harmful

#51

Post by jerf »

Veedrac wrote: post #8
d--b wrote: post #5

> The idea that functions should be small is something that is almost considered too sacrosanct to call into question Errr... Really?! I thought we all agreed that the first rule of programming style is that "it depends"... When they say "small functions", they mean "not the 5000 loc VBA macro that has 50 Boolean arguments, and 30 side effects". Breaking a function that does 1 thing into sub functions just so that ea…

> When they say "small functions", they mean "not the 5000 loc VBA macro that has 50 Boolean arguments, and 30 side effects". Clearly, though, not all of them do. From the article, for context. > The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. > In my Ruby code, half of my methods are just one or two lines long. > Any function more than…

I've heard rumors of people operating under a "all functions must be one line" rule, though I've never encountered it in real life.

Re: Small functions considered harmful

#52

Post by narag »

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…

Unfortunately, I've had the misfortune of working with horrendous programmers who write functions that are hundreds of lines long, duplicated all over the place, and are a pain to understand and maintain.

As a maintanance programmer I had that misfortune very often. But I don't believe it's really so relevant to the article.

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

It doesn't, it's more of a heuristic and, as such, a way of detecting that you might be doing it wrong, not a sound rule to apply.

The problem is exactly that one: people that use "write short functions" as something that you must do. I've suffered such a fool as a boss and it was really sad. The man believed that two lines function (and the calling spagetti that followed) were a superior system to ten lines functions that accomplished a definite goal.

In general the problem is people that use general rules without understanding them.

Re: Small functions considered harmful

#53

Post by densh »

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…

> 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 opposite extreme, and beginning the cycle all over again.

This summarizes perfectly the whole OOP vs FP debate.

Re: Small functions considered harmful

#54

Post by taeric »

jerf wrote: post #50
agentultra wrote: post #44

It seems like the author's idea of the term abstraction is limited to substituting procedures with functions (or worse, class methods). The claims that "all abstractions leak" and that adherence to DRY makes code "hard to follow" is what gives me this impression. This line of thinking happens if you think of code in procedural terms. And if your sense of abstraction is to hide procedural side-effects behind function…

Arguably lambda, monad, etc. are generalizations, not abstractions: http://www.emu.edu.tr/aelci/Courses/D-318/D-318-Files/plbook... Abstractions that don't leak aren't abstractions, as the essense of abstraction is the simplification and removal of detail. Monad is a generalization of a pattern seen in many places, so it doesn't have to "leak".

I call shenanigans. Lambdas can easily lead to leaking call backs as your implementation.

Similarly, monadic style can leak if you are sloppy with it. Just see coffee in Haskel where the IO Monday has infected the entire codebase, and not just a boundary.

Re: Small functions considered harmful

#55

Post by durgiston »

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…

This basically boils down to 'bad code is bad'. DRY and short-functions are supposed to be guidelines, not rules, and when you find yourself violating them, you're supposed to question why. Sometimes there's a good reason for it, often not, and it will help newbies get to the point where they can answer these questions themselves.

Re: Small functions considered harmful

#56

Post by nabla9 »

Functions have several functions.

* Functions can be like new words in a language. If there is new concept that is used frequently, it should be named or abbreviated and maybe listed in a index.

* Functions can sometimes be like chapters or sections. They are entry points listed in table of contents (API description)

* Functions are sometimes used like paragraphs. Used only once to make very long section easier to read. Not really functions. Way to structure text.

For paragraph use we might want blocks of code with function like interface. Code editors could collapse and expand them.

    let a, b, c = 100 
    let p = 0

    paragraph "Intro to foo" (constant a, modify p) {
        let k, l, m, ...

    } assert (p

Re: Small functions considered harmful

#57

Post by imron »

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.

Re: Small functions considered harmful

#58

Post by graphitezepp »

densh wrote: post #53
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…

> 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 opposite extreme, and beginning the cycle all over again. This summarizes perfectly the whole OOP vs FP debate.

Also most of political history.

Re: Small functions considered harmful

#59

Post by jondubois »

The loss of locality argument is a very good one. Having to jump around different files whilst holding layers upon layers of abstractions at the back of your mind to figure out the source of a bug is overwhelming and extremely distracting (you literally need to keep a call stack inside your brain to pull that off).

DRY is all fine until you need more information about the function than what the function name and documentation can provide - Sometimes you actually need to peek inside the code itself.

I don't think that code can ever be 100% black box; especially as you move up higher in the chain of abstraction. This is particularly true for dynamically typed languages - These days in JavaScript I often find myself peeking inside the function's code before I invoke it - It's very easy to make false assumptions about the behaviour of the function based on its name alone and often the documentation isn't enough and doesn't tell you anything about the performance of the function (is it O(1), O(n) or O(n^2)? - You wouldn't want to call an O(n) function whilst in a loop over n because then you'd get very crappy O(n^2) performance).

Re: Small functions considered harmful

#60

Post by mannykannot »

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 also have a bias against '...considered harmful' titles, but that does not invalidate the points being made.

The author is responding to specific examples of respected and influential people advocating a very extreme and dogmatic approach to the issue. As this article does not advocate for large functions, but against going to extremes, it is saying the very things that you say you stand for.

I don't have a good example on hand, but imagine a complicated mathematical expression. Up to a point, writing functions for parts of the expression might well make it easier to understand, but encapsulating each and every operator in a function will not. That, of course, is an absurd idea, but that is the point: it is no more absurd than the idea that anything you might want to see explained in a comment would be better done by creating a function.

It is possible, I believe, to write functions that do less than one thing, and I will be looking for examples - and also for examples where a desire for small functions has been accompanied by the creation of hidden dependencies.

Post reply on HN