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

81–90 of 121 posts

Re: Small functions considered harmful

#81

Post by marcosdumay »

whack wrote: post #62
narag wrote: post #52

Earlier quoted context omitted.

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…

I think even most people who believe in short functions, would disagree with your boss. The following SO thread does a pretty good job summarizing the short-functions principle. https://softwareengineering.stackexchange.com/questions/1334... The whole point of a guideline is that it's not a rule. It's a heuristic that people can selectively apply, based on the specific context and their level of experience.

I haven't yet seen anybody pushing for "short functions" literally that didn't want a hardline on the largest function you should create. Thus, I haven't seen anybody explicitly using it as an heuristic instead of a rule.

People have all kind of heuristics that correlate with short functions, like DRY and single responsibility principle. People do apply those as heuristics. But function length is a number, and it is very hard to keep your conclusions fuzzy when operating over numbers.

Re: Small functions considered harmful

#82

Post by marcosdumay »

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…

Abstract abstractions, that simplify things that aren't real don't leak when you design them well. Concrete abstractions, that simplify things you didn't create do always leak.

Only the second type is essential for programming, and many people do use only them.

Re: Small functions considered harmful

#83

Post by voidhorse »

Programming is like writing. There are some general rules that will usually make your meaning clearer. There are also exceptions. Begin following the rules, prioritize clarity and semantics, identify when breaking a rule would make your meaning clearer and break away.

At the end of the day, you're still just communicating--in communication clarity is key.

You must also keep your audience in mind. Thus, if your company follows conventions you stick to them, as your audience will be able to digest said conventions quickly.

It's all language.

Programming only has the additional wrinkle that you are also communicating with a computer--which prioritizes very different things than human readers (efficiency, memory management, etc.)

Re: Small functions considered harmful

#84

Post by novembermike »

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 pieces of knowledge (money in one, age in another) then I may not be Code DRY but I'm still Knowledge DRY. An easy way to tell the difference is to think about changing one of your functions. If you'd be happy that it changes the behavior everywhere in the function then you're Knowledge DRY. If you're scared, you're just Code DRY.

Re: Small functions considered harmful

#85

Post by kazagistar »

throwanem wrote: post #15

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

The right abstraction means it has to be changed in one place. The wrong abstraction means the change cuts across abstraction boundries, which means changes all over the place, or having to de-abstract and duplicate before making the change anyways. Of that happens frequently, it is a smell that you are abstracting too early and thus building bad abstractions.

Re: Small functions considered harmful

#86

Post by dllthomas »

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…

Yeah, I've been saying that removing accidental similarity isn't improving code but compressing it. "Huffman coding", if you will...

Re: Small functions considered harmful

#87

Post by dllthomas »

mmatants wrote: post #65
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…

Rules like DRY or keeping line counts low are based on surface metrics and definitely lead people to over-fit the model based on incomplete information. Underlying principle of maintainable code is "simply" that it is a concise and flexible expression of knowledge. The "simply" part is in quotation marks because, of course, it takes a good amount of self-awareness and meta-consideration to understand why some ways to…

DRY is not a surface metric, although it is often misunderstood as one.

The original formulation of DRY was:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Elimination of syntactic repetition is not an application of DRY, although application of DRY will often incidentally eliminate syntactic repetition.

Re: Small functions considered harmful

#88

Post by ronjouch »

taeric wrote: post #54
jerf wrote: post #50

Earlier quoted context omitted.

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.

Fun autocorrect barf: monad <- Monday. That being said, I hate IO Mondays too, they're the worst to start the week.

Re: Small functions considered harmful

#89

Post by tomsthumb »

mannykannot wrote: post #60
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 ex…

"Considered harmful" essays considered harmful

http://meyerweb.com/eric/comment/chech.html

Re: Small functions considered harmful

#90

Post by sqeaky »

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.

Post reply on HN