7 ms·

Uncle "Literally who?" Bob claims you should separate your code into as many small functions spread across as many classes as you can and makes a living selling

Uncle "Literally who?" Bob claims you should separate your code into as many small functions spread across as many classes as you can and makes a living selling (proverbial) shovels. John Carmack says you should keep functions long and have the business logic all be encapsulated together for mental cohesion. Carmack makes a living writing software.

rantwasp 5y ago
Uncle Bob makes a living selling snake oil. Which one should we listen to?
watwut 5y ago
I work with long functions right now. It does not give mental cohesion. Instead, it makes it difficult to figure out what author intended to happen.
- cloverich 5y ago
  Or perhaps the length of the function is orthogonal to the quality of the author's code. Make the function as long as necessary to be readable and maintainable by the people most likely to read and maintain it. But that's not a very sellable snippet, nor a rule that can be grokked in 5 minutes.
LorenPechtel 5y ago
Short functions make it much harder for bugs to hide.
- marcosdumay 5y ago
  Bugs favorite place to hide is in interfaces.
- darksaints 5y ago
  Long functions make it much harder for bugs to hide. See what I did there?
CuriouslyC 5y ago
The type of software John writes is different (much more conceptually challenging), and I don't recall him being as big of a proponent of TDD (which is the biggest benefit to small functions). I think the right answer depends on a number of other factors.
zomgwat 5y ago
On the spectrum you've described, I'm progressively shifting from Uncle Bob's end to Carmack's the further I get into my career. I think of it as code density. I've found that high density code is often easier to grok because there's less ceremony to keep in my head (e.g. many long method names that may or may not be named well, jumping around a bunch of files). Of course, there's a point at which code becomes so dense that it again becomes difficult to grok.
hackinthebochs 5y ago
Carmack is literally the top .1% (or higher) of ability and experience. Not to mention has mostly worked in a field with different constraints than most. I don't think looking to him for general development advice is all that useful.
- CyberDildonics 5y ago
  I think the exact opposite. Read the doom source code and you can see that he didn't mess around with trying to put everything into some nonsense function just because he has some part of a larger function that can be scoped and named. The way he wrote programs even back then is very direct. You don't have to jump around into lots of different functions and files for no reason. There aren't many specialized data structures or overly clever syntax tricks to prove how smart he is. There also aren't attempts to write overly general libraries with the idea that they will be reused 100 times in the future. Everything just does what it needs to do directly.
  - hackinthebochs 5y ago
    But why should any of that be aspirational to an "average" developer? It's like learning how to do mathematics by copying Terrence Tao's patterns of behavior. Perhaps Carmack's output is more a function of the programmer than an indication of good practice for average devs.
    - CyberDildonics 5y ago
      I guess I'm still not being clear - when you read John Carmack's programs you realize that it just isn't necessary to do complex nonsense. If you take a look at the doom source code you realize this isn't the cutting edge of mathematics, he is cranking out great software by avoiding all that and using high school algebra (literally and figuratively) instead. While other people spin their wheels sweating over following snake oil bob's pamphlet Carmack is making programs that people want, source code that people want and work that stands the test of time.
MaxBarraclough 5y ago
Carmack's writing on the proper length of functions (although he expresses it in terms of when to inline a function): http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm.... 2014 HN discussion: https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345 A choice quote from Carmack: > The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it. If a function is only called in a single place, the decision is fairly simple. > In almost all cases, code duplication is a greater evil than whatever second order problems arise from functions being called in different circumstances, so I would rarely advocate duplicating code to avoid a function, but in a lot of cases you can still avoid the function by flagging an operation to be performed at the properly controlled time. For instance, having one check in the player think code for health <= 0 && !killed is almost certain to spawn less bugs than having KillPlayer() called in 20 different places.
dang 5y ago
I happen to agree with you and have posted in various HN threads over the years about the research on this, which (for what it's worth) showed that longer functions were less error prone. However, the snarky and nasty way that you made the point makes the comment a bad one for HN, no matter how right you are. Can you please not post that way? We're trying for something quite different here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. It's even more important to stick to the site guidelines when you're right, because otherwise you discredit the truth and give people a reason to reject it, which harms all of us. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=truth%20discredit%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

rantwasp 5y ago

Uncle Bob makes a living selling snake oil. Which one should we listen to?

watwut 5y ago

I work with long functions right now. It does not give mental cohesion. Instead, it makes it difficult to figure out what author intended to happen.

cloverich 5y ago
Or perhaps the length of the function is orthogonal to the quality of the author's code. Make the function as long as necessary to be readable and maintainable by the people most likely to read and maintain it. But that's not a very sellable snippet, nor a rule that can be grokked in 5 minutes.

LorenPechtel 5y ago

Short functions make it much harder for bugs to hide.

marcosdumay 5y ago
Bugs favorite place to hide is in interfaces.
darksaints 5y ago
Long functions make it much harder for bugs to hide. See what I did there?

CuriouslyC 5y ago

The type of software John writes is different (much more conceptually challenging), and I don't recall him being as big of a proponent of TDD (which is the biggest benefit to small functions). I think the right answer depends on a number of other factors.

zomgwat 5y ago

On the spectrum you've described, I'm progressively shifting from Uncle Bob's end to Carmack's the further I get into my career. I think of it as code density. I've found that high density code is often easier to grok because there's less ceremony to keep in my head (e.g. many long method names that may or may not be named well, jumping around a bunch of files). Of course, there's a point at which code becomes so dense that it again becomes difficult to grok.

hackinthebochs 5y ago

Carmack is literally the top .1% (or higher) of ability and experience. Not to mention has mostly worked in a field with different constraints than most. I don't think looking to him for general development advice is all that useful.

CyberDildonics 5y ago
I think the exact opposite. Read the doom source code and you can see that he didn't mess around with trying to put everything into some nonsense function just because he has some part of a larger function that can be scoped and named. The way he wrote programs even back then is very direct. You don't have to jump around into lots of different functions and files for no reason. There aren't many specialized data structures or overly clever syntax tricks to prove how smart he is. There also aren't attempts to write overly general libraries with the idea that they will be reused 100 times in the future. Everything just does what it needs to do directly.
- hackinthebochs 5y ago
  But why should any of that be aspirational to an "average" developer? It's like learning how to do mathematics by copying Terrence Tao's patterns of behavior. Perhaps Carmack's output is more a function of the programmer than an indication of good practice for average devs.
  - CyberDildonics 5y ago
    I guess I'm still not being clear - when you read John Carmack's programs you realize that it just isn't necessary to do complex nonsense. If you take a look at the doom source code you realize this isn't the cutting edge of mathematics, he is cranking out great software by avoiding all that and using high school algebra (literally and figuratively) instead. While other people spin their wheels sweating over following snake oil bob's pamphlet Carmack is making programs that people want, source code that people want and work that stands the test of time.

MaxBarraclough 5y ago

Carmack's writing on the proper length of functions (although he expresses it in terms of when to inline a function): http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm.... 2014 HN discussion: https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345 A choice quote from Carmack: > The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it. If a function is only called in a single place, the decision is fairly simple. > In almost all cases, code duplication is a greater evil than whatever second order problems arise from functions being called in different circumstances, so I would rarely advocate duplicating code to avoid a function, but in a lot of cases you can still avoid the function by flagging an operation to be performed at the properly controlled time. For instance, having one check in the player think code for health <= 0 && !killed is almost certain to spawn less bugs than having KillPlayer() called in 20 different places.

dang 5y ago

I happen to agree with you and have posted in various HN threads over the years about the research on this, which (for what it's worth) showed that longer functions were less error prone. However, the snarky and nasty way that you made the point makes the comment a bad one for HN, no matter how right you are. Can you please not post that way? We're trying for something quite different here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. It's even more important to stick to the site guidelines when you're right, because otherwise you discredit the truth and give people a reason to reject it, which harms all of us. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=truth%20discredit%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...