3 ms·

Eh, hard disagree. (Though I didn't downvote you, since it's silly to downvote out of disagreement...) Readability, while subjective, plays a large role in sof

by imiric 1y ago

Eh, hard disagree. (Though I didn't downvote you, since it's silly to downvote out of disagreement...) Readability, while subjective, plays a large role in software maintenance. Developers will be more reluctant to change code they don't understand, and more likely to introduce bugs. "Long" functions require following large blocks of code that work within the same context, and relying on comments to explain functionality, which could be wrong or outdated, rather than descriptive function names. Also, "long" functions are typically difficult to test. They either require complex setup and mocking, or are only tested under very specific conditions in end-to-end tests, if at all. Chances are that only users are actually testing them, which is not a good place to be. We can argue whether "AI" tools help with this or not, but while humans are still reading and writing code, following standard conventions of keeping functions relatively "short", "clean" (whatever those terms mean for you and your team), and with a single purpose, makes maintenance and testing easier, and, in turn, produces more robust and higher quality software.

epolanski 1y ago
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?

by imiric 1y ago

epolanski 1y ago

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?