4 ms·

Back when I took a Comp sci course 16 years ago (shit) I was taught that a single function should try to fit within a screen. The idea is that breaking a task u

Back when I took a Comp sci course 16 years ago (shit) I was taught that a single function should try to fit within a screen. The idea is that breaking a task up into digestible steps would both harbor more readable code, self-documentation and code reuse.

MrPatan 4y ago
Good idea, wrong metric. What should fit in a screen is the concept. If you take a big, hairy, complicated thing and just chop it into several functions that fit on a screen you have gained nothing.
- saulpw 4y ago
  If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.
  - commandersaki 4y ago
    Probably a good case for inclining: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
    - thfuran 4y ago
      Inlining is the compiler's job, not mine.
      - commandersaki 4y ago
        You probably should read the article as Carmack makes the case for inlining as a style, not inlining as an optimisation.
        thfuran 4y ago
        I did read the article. I think I'm less in favor of that style than he is (or at least was), but even he said that the problems it addresses arise from subroutines not being pure functions and so isn't a proponent of it in the case the comment you replied to was describing. And when not writing in that style, inlining is for the compiler to do.
        commandersaki 4y ago
        The original poster said if you chop a big hairy complicated thing into functions to fit on a screen you've gained nothing. The response is that if they're named reasonably and pure then you have. Now the reason I posted that inlining article from Carmack leans heavily into this line of advice: "if a function is only called from a single place, consider inlining it." Taking a complicated mess and breaking it into functions that are called from a single place seems better served by organising the code (maybe with duplication if needed) and writing inline comments rather than devoting a call tree to that section of code.
- rzzzt 4y ago
  That's when you rotate the display to vertical orientation.
- justinator 4y ago
  "big, hairy, complicated thing" is a code smell and you would consider doing something about it, before it becomes truly a monster. Breaking it up into its constituent parts may be the way to go, if only because my brain's CPU cache is about 8 bytes of faulty memory.
mcphage 4y ago
> The idea is that breaking a task up into digestible steps would both harbor more readable code, self-documentation and code reuse. Sometimes. Other times it means you need to jump around in a file (or jump between files, even) to understand what's going on.
- wizofaus 4y ago
  Which is fine - any software of non-trivial complexity is going to require looking at the behaviour of multiple execution units, which may well be in different files. But if they're named sensibly and the dependencies are clearly maintained, the typical programmer is going to have a much easier time of "understand[ing] what's going on" than a single huge largely-unstructured blob of code. The moment you can't quickly see where a block starts and ends (without using IDE shortcuts) then the code has a readability issue.

MrPatan 4y ago

Good idea, wrong metric. What should fit in a screen is the concept. If you take a big, hairy, complicated thing and just chop it into several functions that fit on a screen you have gained nothing.

saulpw 4y ago
If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.
- commandersaki 4y ago
  Probably a good case for inclining: http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html http://number-none.com/blow/blog/programming/2014/09/26/carm...
  - thfuran 4y ago
    Inlining is the compiler's job, not mine.
    - commandersaki 4y ago
      You probably should read the article as Carmack makes the case for inlining as a style, not inlining as an optimisation.
      - thfuran 4y ago
        I did read the article. I think I'm less in favor of that style than he is (or at least was), but even he said that the problems it addresses arise from subroutines not being pure functions and so isn't a proponent of it in the case the comment you replied to was describing. And when not writing in that style, inlining is for the compiler to do.
        commandersaki 4y ago
        The original poster said if you chop a big hairy complicated thing into functions to fit on a screen you've gained nothing. The response is that if they're named reasonably and pure then you have. Now the reason I posted that inlining article from Carmack leans heavily into this line of advice: "if a function is only called from a single place, consider inlining it." Taking a complicated mess and breaking it into functions that are called from a single place seems better served by organising the code (maybe with duplication if needed) and writing inline comments rather than devoting a call tree to that section of code.
rzzzt 4y ago
That's when you rotate the display to vertical orientation.
justinator 4y ago
"big, hairy, complicated thing" is a code smell and you would consider doing something about it, before it becomes truly a monster. Breaking it up into its constituent parts may be the way to go, if only because my brain's CPU cache is about 8 bytes of faulty memory.

mcphage 4y ago

> The idea is that breaking a task up into digestible steps would both harbor more readable code, self-documentation and code reuse. Sometimes. Other times it means you need to jump around in a file (or jump between files, even) to understand what's going on.

wizofaus 4y ago
Which is fine - any software of non-trivial complexity is going to require looking at the behaviour of multiple execution units, which may well be in different files. But if they're named sensibly and the dependencies are clearly maintained, the typical programmer is going to have a much easier time of "understand[ing] what's going on" than a single huge largely-unstructured blob of code. The moment you can't quickly see where a block starts and ends (without using IDE shortcuts) then the code has a readability issue.