4 ms·

Yes, it's much better code that solves all kinds of hidden problems in the second style. The second style seems ok to you, then you've not yet learned the benef

by zorga 8y ago

Yes, it's much better code that solves all kinds of hidden problems in the second style. The second style seems ok to you, then you've not yet learned the benefits of abstraction nor of bottom up programming. It's easier to build simpler programs when you build them from many simple parts. It's easier to build parts if they do one thing. It's easier to test everything if they're all separate things. It's easier to reuse logic when they're separate things. It's easier to fix bugs when they're separate things. It's easier to separate implementation and interface, i.e. low level vs high level logic. It's easier to plug in alternate implementations when they're each separate things. That all adds up to being much easier to write, evolve, and grow a system using the first approach than with the second.

dasmoth 8y ago
Abstractions are great. But in my experience the kind of functions you get by pulling chunks out of a big (but working) function aren't often abstracting things that are terribly valuable. If you think the extracted function does make sense on its own, then of course go for it! But if in doubt, I'd prefer to wait until there's actually a second call site to make the motivation for the extracted function clearer (and stand a better chance of getting its interface right first time).
- zorga 8y ago
  Function abstraction is not only about reuse, it's about separating the high level details from the low level details. Separating the flow of logic, from the details of each step, is always valuable and should be done right from the start; replacing an inline implementation with a function name with args is abstraction even when it's not ever reused and it greatly improves the code. Big methods that do many things inline with commented sections explaining what the section does, is bad programming. It allows variable reuse and hidden weird dependencies between what should be independent chunks of code in independent functions. It also forces the programmer reading it to always work at the lowest level of implementation rather than a higher level of abstraction where he can see the flow without needing to see all the details of each step. If you can point to a section of code, and put a comment on it saying it does X, then it belongs in a function named X and the comment needs deleted. Comments that explain what code does are a code smell. Comments are for explaining why, not what. There shouldn't be any big functions to begin with except in a few rare cases like switching on a character or something.

by zorga 8y ago

dasmoth 8y ago

Abstractions are great. But in my experience the kind of functions you get by pulling chunks out of a big (but working) function aren't often abstracting things that are terribly valuable. If you think the extracted function does make sense on its own, then of course go for it! But if in doubt, I'd prefer to wait until there's actually a second call site to make the motivation for the extracted function clearer (and stand a better chance of getting its interface right first time).

zorga 8y ago
Function abstraction is not only about reuse, it's about separating the high level details from the low level details. Separating the flow of logic, from the details of each step, is always valuable and should be done right from the start; replacing an inline implementation with a function name with args is abstraction even when it's not ever reused and it greatly improves the code. Big methods that do many things inline with commented sections explaining what the section does, is bad programming. It allows variable reuse and hidden weird dependencies between what should be independent chunks of code in independent functions. It also forces the programmer reading it to always work at the lowest level of implementation rather than a higher level of abstraction where he can see the flow without needing to see all the details of each step. If you can point to a section of code, and put a comment on it saying it does X, then it belongs in a function named X and the comment needs deleted. Comments that explain what code does are a code smell. Comments are for explaining why, not what. There shouldn't be any big functions to begin with except in a few rare cases like switching on a character or something.