12 ms·
> I couldn't disagree more. In fact it's an incredibly "junior dev" mindset that sees 2 pieces of similar (or _even identical_) code and is compelled to abstrac
by jamil7 3y ago
> I couldn't disagree more. In fact it's an incredibly "junior dev" mindset that sees 2 pieces of similar (or _even identical_) code and is compelled to abstract it. Unless there are at a _minimum_ of 3 implementations I think it's always better to duplicate. I've watched too many "common" functions grow over time with way too many arguments, too many conditionals, and way too confusing for anyone to easily follow. The most egregious is different return values based on arguments passed in. I'm not talking "array of strings" or "null" but "array of strings" or "single string" (or worse).
I agree with you here and tend to rather, if possible, deduplicate subsystems or sub-functions of similar looking/identical code and keep the duplicate public surfaces.
- joshstrange 3y ago> I agree with you here and tend to rather, if possible, deduplicate subsystems or sub-functions of similar looking/identical code and keep the duplicate public surfaces. Completely agree, take the small parts that are standalone/discrete and abstract them. I greatly prefer something like function1() { commonCode1(); commonCode2(); commonCode4(); } function2() { commonCode2(); commonCode3(); commonCode4(); } Over something like (assume I've inlined the commonCodeX logic): functionCommon(branchingParam) { if(branchingParam) { commonCode1(); } commonCode2(); if(!branchingParam) { commonCode3(); } commonCode4(); }