3 ms·

Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. You don'

Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body. When you read the code you the function name and return type can describe what is being done rather than trying to grok the body of the function code itself.

adnzzzzZ 11y ago
It might make the code more readable but it makes you jump around more and adds more complexity to the code base. Now you have to consider: under what conditions does this function get called? Does it get called more than once? In which file is it? And so on. Every time you add another node to your code base you're making it more complex, and in this instance it has very questionable gains. It makes as much sense to just say in the first line of this block of functionality what it does to what.
- WatchDog 11y ago
  I guess im used to working with languages with excellent IDE support. Having more files and jumping around the code to see the detail don't seem to be a problem for me when using a good IDE. While I only got through around half the video I can see hes created 500 line functions with 5 levels of flow control, personally I find that much harder to follow than clicking though to a function or just reading he functions name and API.
  - Narishma 11y ago
    Those 500 line functions include private sub-functions though.
loup-vaillant 11y ago
> Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. The key point is discrete. If you fail to carve the program at its joints, and no more, you'll only make it worse. I too separate functions even if they're called only once. I just require that the interface of the function be easier to understand than its implementation. That's not always true, especially for short, impure functions. > You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body. I don't need functions to do that. I'm not writing JavaScript. Here: { int foo; float bar; baz(foo, bar); { int wiz; float woo; wak(wiz, woo); } klo(); // klonk(wiz); // error: wiz not in scope } > When you read the code you the function name and return type can describe what is being done rather than trying to grok the body of the function code itself. I can still put comments. They notoriously rot, but the same is true of function names. Plus, comments aren't restricted to identifiers, so I can write plain English: { // ... { // Waks the wiz with the woo int wiz; float woo; wak(wiz, woo); } // ... }

adnzzzzZ 11y ago

It might make the code more readable but it makes you jump around more and adds more complexity to the code base. Now you have to consider: under what conditions does this function get called? Does it get called more than once? In which file is it? And so on. Every time you add another node to your code base you're making it more complex, and in this instance it has very questionable gains. It makes as much sense to just say in the first line of this block of functionality what it does to what.

WatchDog 11y ago
I guess im used to working with languages with excellent IDE support. Having more files and jumping around the code to see the detail don't seem to be a problem for me when using a good IDE. While I only got through around half the video I can see hes created 500 line functions with 5 levels of flow control, personally I find that much harder to follow than clicking though to a function or just reading he functions name and API.
- Narishma 11y ago
  Those 500 line functions include private sub-functions though.

loup-vaillant 11y ago

> Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. The key point is discrete. If you fail to carve the program at its joints, and no more, you'll only make it worse. I too separate functions even if they're called only once. I just require that the interface of the function be easier to understand than its implementation. That's not always true, especially for short, impure functions. > You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body. I don't need functions to do that. I'm not writing JavaScript. Here: { int foo; float bar; baz(foo, bar); { int wiz; float woo; wak(wiz, woo); } klo(); // klonk(wiz); // error: wiz not in scope } > When you read the code you the function name and return type can describe what is being done rather than trying to grok the body of the function code itself. I can still put comments. They notoriously rot, but the same is true of function names. Plus, comments aren't restricted to identifiers, so I can write plain English: { // ... { // Waks the wiz with the woo int wiz; float woo; wak(wiz, woo); } // ... }