9 ms·

You break up things when it makes sense, not for the sake of it. Having to jump out of the code you're reading comes with its own downsides and tends to compro

You break up things when it makes sense, not for the sake of it. Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (same functionality, but higher api surface). You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of syscalls run generously in the thousands or tens of thousands of lines. Stanford professor Jon Ousterhout (among other things the author of the Tcl language, the Tk framework, the Raft consensus algorithm and many other things) has an entire paragraph in his book "A philosophy of software design"[1], on why the argument "functions should be short" is short sighted and should never be taken at face value. [1] https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

imiric 1y ago
> You break up things when it makes sense, not for the sake of it. I never claimed otherwise. > Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (higher api surface). I don't buy this argument. The code you're reading should do one thing according to what it says on the tin (the function name). When the code does something else, you navigate to that other place (easily done in most IDEs), and change contexts. This context change is important, since humans struggle with keeping track of a lot of it at once. When you have to follow a single long function, the context is polluted with previous functionality, comments, variables, and so on, not unlike the scope of the program at that point. If you're changing the code, it becomes easier to shadow a previous variable, or to change something that subsequent code depends on. Decomposing the large function into smaller ones avoids all of this. As well as aiding in testability, which you conveniently ignored from my previous comment. The criteria for determining what is "short" and "long" is subjective, of course, and should be determined by whatever the team collectively agrees on. But there should be some accepted definition of these. > Stanford professor Jon Ousterhout Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours.
- epolanski 1y ago
  > Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours. John has spent his entire life to learning and teaching general principles of good software design and their limits. His opinion definitely has a different weight than ours. https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/index.php https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/inde...
  - illuminator83 1y ago
    Well, he can start citing Martin Fowler or Bertrand Meyer. Then what? Arguments from authority lead no where here. Because these "authorities" also disagree.
    - epolanski 1y ago
      John has had meaningful impact to computing from algos, operating systems, programming languages, frameworks, etc. Fowler has written *nothing* anybody ever cared for. Nothing. Ousterhout has taught Software Design at Stanford where he's had students implement the most diverse software and finding the limits of his own theories and having them questioned rigorously year after year.
- vendiddy 1y ago
  If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right? Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same? Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow. So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months. Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?

imiric 1y ago

> You break up things when it makes sense, not for the sake of it. I never claimed otherwise. > Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (higher api surface). I don't buy this argument. The code you're reading should do one thing according to what it says on the tin (the function name). When the code does something else, you navigate to that other place (easily done in most IDEs), and change contexts. This context change is important, since humans struggle with keeping track of a lot of it at once. When you have to follow a single long function, the context is polluted with previous functionality, comments, variables, and so on, not unlike the scope of the program at that point. If you're changing the code, it becomes easier to shadow a previous variable, or to change something that subsequent code depends on. Decomposing the large function into smaller ones avoids all of this. As well as aiding in testability, which you conveniently ignored from my previous comment. The criteria for determining what is "short" and "long" is subjective, of course, and should be determined by whatever the team collectively agrees on. But there should be some accepted definition of these. > Stanford professor Jon Ousterhout Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours.

epolanski 1y ago
> Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours. John has spent his entire life to learning and teaching general principles of good software design and their limits. His opinion definitely has a different weight than ours. https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/index.php https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/inde...
- illuminator83 1y ago
  Well, he can start citing Martin Fowler or Bertrand Meyer. Then what? Arguments from authority lead no where here. Because these "authorities" also disagree.
  - epolanski 1y ago
    John has had meaningful impact to computing from algos, operating systems, programming languages, frameworks, etc. Fowler has written *nothing* anybody ever cared for. Nothing. Ousterhout has taught Software Design at Stanford where he's had students implement the most diverse software and finding the limits of his own theories and having them questioned rigorously year after year.
vendiddy 1y ago
If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right? Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same? Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow. So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months. Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?