5 ms·
There's an easier approach that will also aid you in telling you how to precisely chop up your function. Simply don't chop up your function until you need a sl
by erhaetherth 3y ago
There's an easier approach that will also aid you in telling you how to precisely chop up your function.
Simply don't chop up your function until you need a slice of it somewhere else. Then refactor out the bit you need. You'll find out exactly which bits need to be replaced with variables and exactly where the slice needs to happen.
- atq2119 3y agoThis is the correct answer right here if you have a good enough team. It is still the way I want to work. Unfortunately, I find that there are too many developers who haven't learned that you should always be considering to "refactor as you go". I'm trying to teach by example, but it's an uphill battle.
- pstuart 3y agoExactly. Start with the straight-ahead linear approach and factor out once it's unwieldy. Same thing for copy pasta funcs -- the first copy is fine, the second one may be too, but after that consider extracting to a parameterized func (a permutation of the Go Proverb "A little copying is better than a little dependency.")
- kaba0 3y agoA single use function absolutely makes sense - you are effectively naming a block of code in some way, documenting it.