4 ms·

> It's like trying to read a book with each sentence reference a different page. Yes!!! I've been trying to teach Juniors that if the function itself has 4 lev

> It's like trying to read a book with each sentence reference a different page. Yes!!! I've been trying to teach Juniors that if the function itself has 4 levels of abstraction, even if the names are readableFunctionThatDoesXwithYSideEffect ..... it is harder to understand, Ctrl+clicking downards into each little mini-rabbit -hole. Just keep the function as a 80-liner, not a 20-liner with 4 levels of indirection w/ functions that are only used once (inside parent function) ugh.

methodsignature 6y ago
They all probably read Clean Code, the discussion on functions in that book may be the most harmful/costly to programming in the last 20 years.
- IggleSniggle 6y ago
  Clean Code is still a great read in 2020, but I think you’re right about some of the specific advice about functions.
- abledon 6y ago
  Is there a good blogpost/writeup on this idea? I've seen it mentioned before in other threads.... And i agree 100%
  - tekdude 6y ago
    From John Carmack: 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...
    - UK-Al05 6y ago
      That's a for a specific case of high performance code and removing duplicated work. Referencing carmwack always has to be in the context of high performance code. Even carmack himself has started like functional code. Which normally leads you down small pure functions.
      - smaddox 6y ago
        No, that is not for a specific case of high performance... It's for the non-specific case of keeping the code clear, understandable, and bug-free. The style was chosen for these reasons, not because it is more performant. It just happens to also be more performant than the layers of indirection that also harm understandability. For a procedural code base, avoid subprocedures that are only called once. For a pure functional codebase, e.g. Haskell, locally-scoped single-use functions can be beneficial.
bitexploder 6y ago
The key concept they always helps me is to minimize side effects per function. One thing goes in, one thing comes out (in an abstract sense). Multiple side effects starts getting dodgy as it makes the function harder to predict and reason about. I do err for longer easier to read functions. And don’t compose into functions until it’s clear you will actually reuse the code or you actually need to reuse it :) DRY is good but premature composition is just as annoying as premature optimization.
- chrisweekly 6y ago
  Yes! "AHA" (Avoid Hasty Abstractions) is the remedy to too much "DRY".
kvothe_ 6y ago
I think you may find it difficult to test an 80 liner... There is way too much happening.
- bitexploder 6y ago
  Depends on the language. In general I find the way many unit tests are written to be very brittle. There is a balance here. If the 80 lines are clear and easy to understand they will likely be easy to test also. It’s very situational though. An 80 line function isn’t that bad. Check out the SQLite code base, which is extremely well tested, or the linux kernel. C code tends to push out the line count. Whereas 80 in Python is probably a bit much. Some libraries, especially GUI code tend to take a lot of lines, mostly just handling events and laying things out and there you often see big functions as well.
- abledon 6y ago
  its java
- ratww 6y ago
  You still have to test all the 80 lines if they're broken down into multiple functions, so it's something that you have to evaluate on a case-by-case basis. It might even make it harder to test: if you break a function wrong, then you might end up with a group of functions that only work together anyway. For example: when you break a big function into 3 smaller ones. If the first acquires a resource (transaction, file) and the third releases it, then it might be simpler to test the whole group rather than each one separately.
- smaddox 6y ago
  Breaking an 80 line function into to 8x 10 line functions does not necessarily make it easier to test. Most of the time it just adds unit testing busy work, for no clear benefit. This becomes more clear if you imagine you wanted to test every possible input. Splitting the function in 8ths introduces roughly 8x the work, if each new function has the same number of possible input states. The math is more complicated in the general case, so you have to evaluate it on a case-by-case basis. Also, if you're trying to isolate a known bug, it might be beneficial to split the function and test each part in isolation.

methodsignature 6y ago

They all probably read Clean Code, the discussion on functions in that book may be the most harmful/costly to programming in the last 20 years.

IggleSniggle 6y ago
Clean Code is still a great read in 2020, but I think you’re right about some of the specific advice about functions.
abledon 6y ago
Is there a good blogpost/writeup on this idea? I've seen it mentioned before in other threads.... And i agree 100%
- tekdude 6y ago
  From John Carmack: 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...
  - UK-Al05 6y ago
    That's a for a specific case of high performance code and removing duplicated work. Referencing carmwack always has to be in the context of high performance code. Even carmack himself has started like functional code. Which normally leads you down small pure functions.
    - smaddox 6y ago
      No, that is not for a specific case of high performance... It's for the non-specific case of keeping the code clear, understandable, and bug-free. The style was chosen for these reasons, not because it is more performant. It just happens to also be more performant than the layers of indirection that also harm understandability. For a procedural code base, avoid subprocedures that are only called once. For a pure functional codebase, e.g. Haskell, locally-scoped single-use functions can be beneficial.

bitexploder 6y ago

The key concept they always helps me is to minimize side effects per function. One thing goes in, one thing comes out (in an abstract sense). Multiple side effects starts getting dodgy as it makes the function harder to predict and reason about. I do err for longer easier to read functions. And don’t compose into functions until it’s clear you will actually reuse the code or you actually need to reuse it :) DRY is good but premature composition is just as annoying as premature optimization.

chrisweekly 6y ago
Yes! "AHA" (Avoid Hasty Abstractions) is the remedy to too much "DRY".

kvothe_ 6y ago

I think you may find it difficult to test an 80 liner... There is way too much happening.

bitexploder 6y ago
Depends on the language. In general I find the way many unit tests are written to be very brittle. There is a balance here. If the 80 lines are clear and easy to understand they will likely be easy to test also. It’s very situational though. An 80 line function isn’t that bad. Check out the SQLite code base, which is extremely well tested, or the linux kernel. C code tends to push out the line count. Whereas 80 in Python is probably a bit much. Some libraries, especially GUI code tend to take a lot of lines, mostly just handling events and laying things out and there you often see big functions as well.
abledon 6y ago
its java
ratww 6y ago
You still have to test all the 80 lines if they're broken down into multiple functions, so it's something that you have to evaluate on a case-by-case basis. It might even make it harder to test: if you break a function wrong, then you might end up with a group of functions that only work together anyway. For example: when you break a big function into 3 smaller ones. If the first acquires a resource (transaction, file) and the third releases it, then it might be simpler to test the whole group rather than each one separately.
smaddox 6y ago
Breaking an 80 line function into to 8x 10 line functions does not necessarily make it easier to test. Most of the time it just adds unit testing busy work, for no clear benefit. This becomes more clear if you imagine you wanted to test every possible input. Splitting the function in 8ths introduces roughly 8x the work, if each new function has the same number of possible input states. The math is more complicated in the general case, so you have to evaluate it on a case-by-case basis. Also, if you're trying to isolate a known bug, it might be beneficial to split the function and test each part in isolation.