4 ms·

I typically find it very difficult to understand complex functions, (100+ lines of code, ~3 or more nesting levels deep) and even simpler complex functions (mix

I typically find it very difficult to understand complex functions, (100+ lines of code, ~3 or more nesting levels deep) and even simpler complex functions (mixing 2-3 concepts into a 15 line function). I've only just started doing TDD the "Growing Object Oriented Software guided by tests" way, and I find it incredibly helpful that each and every class does just _one_ thing, even splitting up those 15 line functions into two or three separate classes implementing an interface -- single responsibility -- helps me a lot in reasoning about the code. I _have_ experienced the dependencies issue myself already though, it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying.

kosievdmerwe 7y ago
Yeah, but I would say it depends on context, clarity is very context dependent. Do what makes the code easiest to read taking into account that human limitations. Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. For instance, logic that filters what jobs to run based on conditions, it might make sense to abstract the logic for the conditions into one class per condition, to make the filtering logic clearer.
- azeirah 7y ago
  > Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. Yeah, that seems to be something I'll have to spend some time learning about. Right now I'm just mindlessly splitting off everything, and it kind of works, but it's annoying to navigate all over the place just to find some detail somewhere
jpittis 7y ago
> I typically find it very difficult to understand complex functions It seems to me like "complex" and "ability to understand" mean the same thing, so this phrase doesn't have much meaning. It's difficult to define "ability to understand" / "complex" without using either of those words in the definition. For example, you mention lines of code, nesting and multiple concepts. I tend to agree with your examples, however not necessarily the lines of code. I've seen single large functions that represent an algorithm in a way that's easier to understand than the implementation that breaks it up into tens of little functions. It made liberal use of comments to explain each section of code in the function. I believe its advantage was that when reading, you could simply scroll down the function line by line rather than having to jump all over the file.
- azeirah 7y ago
  Sure, all I mean is that I get frustrated and lose unnecessarily much time being distracted by keeping a model of how the function works and how variables interact in my head. I have ADHD so my working memory isn't fantastic for these kinds of functions. I suppose you could take my definition of complexity to be approximate to cyclomatic complexity
- JamesBarney 7y ago
  Local functions are also really handy when you want to break up a large function into smaller pieces but keep them localized.
dang 7y ago
This is widely believed and repeated, but empirical evidence actually runs the other way: according to studies cited in the book Code Complete, functions in the range of 100 to 150 LOC are more maintainable than shorter ones. https://news.ycombinator.com/item?id=6229801 https://news.ycombinator.com/item?id=6229801 https://news.ycombinator.com/item?id=3876434 https://news.ycombinator.com/item?id=3876434 https://hn.algolia.com/?query=by:cpeterso%20%22code%20complete%22%20function&sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0 https://hn.algolia.com/?query=by:cpeterso%20%22code%20comple...
- BurningFrog 7y ago
  At the end of the day, a simple measure like LOC can never capture readability, good or bad, and you get eaten by Goodhart's Law if you focus too much on it. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
  - smitty1e 7y ago
    Oh, save us from the scenes, Where the end becomes the means, And the forest gets so lost among the trees; When polishing the source, Blunts all our creative force, And procedure kills the genius it claims it frees.
  - dang 7y ago
    No one would argue otherwise. Indeed, you can trivially take any readable function and transform it into an unreadable one of exactly the same length. But this doesn't seem like a valid reason to dismiss specific findings of specific studies. Don't you think it's interesting that such research as we have contradicts the most often-repeated claim about this aspect of programming?
    - BurningFrog 7y ago
      I don't know. I've learned over the years that there is always a study confirming or contradicting whatever point you want to make. "Beware The Man Of One Study". I say that without even looking at those studies, which is perhaps unfair. But there are So Many Studies... My personal experience is that when I was exposed to shorter simple and (so important!) well named functions, my work became so much better. And that is now the school I subscribe to. That's not - at all - to say you can't also find very good practices doing different things. But that's not where I found it.
blub 7y ago
I have a theory about why this functional atomization has become so popular: small design topics (functions, classes) are easy to talk about so the various wannabe OOP gurus like Robert Martin keep talking about them the most, becoming more and more extreme to the point that we end up with hundreds of one line functions which can only really be put together in one way so that they fulfill the arbitrary criteria of reading like prose. This is an excellent example of local optimizations - i.e. local design optimizations - which end up harming the overall design and maintainability. You've discovered this yourself, but still cling to this dogma of tiny functions.
- azeirah 7y ago
  I made it clear that there are upsides. It's a tradeoff, not "gurus bad".
PhilippGille 7y ago
> it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying. The IDE should be able to show you the implementations. When using Java and Eclipse for example, you just hold Ctrl and hover with the mouse over a method call. In the appearing dialogue you can then select "Go to implementation" instead of "Go to definition" (or similar) and Eclipse searches for and then shows you all classes that contain an override for that method and then you can click on one of them to view that specific overriding method.

kosievdmerwe 7y ago

Yeah, but I would say it depends on context, clarity is very context dependent. Do what makes the code easiest to read taking into account that human limitations. Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. For instance, logic that filters what jobs to run based on conditions, it might make sense to abstract the logic for the conditions into one class per condition, to make the filtering logic clearer.

azeirah 7y ago
> Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. Yeah, that seems to be something I'll have to spend some time learning about. Right now I'm just mindlessly splitting off everything, and it kind of works, but it's annoying to navigate all over the place just to find some detail somewhere

jpittis 7y ago

> I typically find it very difficult to understand complex functions It seems to me like "complex" and "ability to understand" mean the same thing, so this phrase doesn't have much meaning. It's difficult to define "ability to understand" / "complex" without using either of those words in the definition. For example, you mention lines of code, nesting and multiple concepts. I tend to agree with your examples, however not necessarily the lines of code. I've seen single large functions that represent an algorithm in a way that's easier to understand than the implementation that breaks it up into tens of little functions. It made liberal use of comments to explain each section of code in the function. I believe its advantage was that when reading, you could simply scroll down the function line by line rather than having to jump all over the file.

azeirah 7y ago
Sure, all I mean is that I get frustrated and lose unnecessarily much time being distracted by keeping a model of how the function works and how variables interact in my head. I have ADHD so my working memory isn't fantastic for these kinds of functions. I suppose you could take my definition of complexity to be approximate to cyclomatic complexity
JamesBarney 7y ago
Local functions are also really handy when you want to break up a large function into smaller pieces but keep them localized.

dang 7y ago

This is widely believed and repeated, but empirical evidence actually runs the other way: according to studies cited in the book Code Complete, functions in the range of 100 to 150 LOC are more maintainable than shorter ones. https://news.ycombinator.com/item?id=6229801 https://news.ycombinator.com/item?id=6229801 https://news.ycombinator.com/item?id=3876434 https://news.ycombinator.com/item?id=3876434 https://hn.algolia.com/?query=by:cpeterso%20%22code%20complete%22%20function&sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0 https://hn.algolia.com/?query=by:cpeterso%20%22code%20comple...

BurningFrog 7y ago
At the end of the day, a simple measure like LOC can never capture readability, good or bad, and you get eaten by Goodhart's Law if you focus too much on it. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- smitty1e 7y ago
  Oh, save us from the scenes, Where the end becomes the means, And the forest gets so lost among the trees; When polishing the source, Blunts all our creative force, And procedure kills the genius it claims it frees.
- dang 7y ago
  No one would argue otherwise. Indeed, you can trivially take any readable function and transform it into an unreadable one of exactly the same length. But this doesn't seem like a valid reason to dismiss specific findings of specific studies. Don't you think it's interesting that such research as we have contradicts the most often-repeated claim about this aspect of programming?
  - BurningFrog 7y ago
    I don't know. I've learned over the years that there is always a study confirming or contradicting whatever point you want to make. "Beware The Man Of One Study". I say that without even looking at those studies, which is perhaps unfair. But there are So Many Studies... My personal experience is that when I was exposed to shorter simple and (so important!) well named functions, my work became so much better. And that is now the school I subscribe to. That's not - at all - to say you can't also find very good practices doing different things. But that's not where I found it.

blub 7y ago

I have a theory about why this functional atomization has become so popular: small design topics (functions, classes) are easy to talk about so the various wannabe OOP gurus like Robert Martin keep talking about them the most, becoming more and more extreme to the point that we end up with hundreds of one line functions which can only really be put together in one way so that they fulfill the arbitrary criteria of reading like prose. This is an excellent example of local optimizations - i.e. local design optimizations - which end up harming the overall design and maintainability. You've discovered this yourself, but still cling to this dogma of tiny functions.

azeirah 7y ago
I made it clear that there are upsides. It's a tradeoff, not "gurus bad".

PhilippGille 7y ago

> it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying. The IDE should be able to show you the implementations. When using Java and Eclipse for example, you just hold Ctrl and hover with the mouse over a method call. In the appearing dialogue you can then select "Go to implementation" instead of "Go to definition" (or similar) and Eclipse searches for and then shows you all classes that contain an override for that method and then you can click on one of them to view that specific overriding method.