Timeline for What's the alternative to DRY code when it requires too many parameters?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2015 at 14:19 | comment | added | Doc Brown | @gexicide: I agree mostly, but from my own experience from larger projects, I have learned the hard way that DRY should only be enforced inside of one software product. If you have different products with different life cycles, you will have to trade off between the DRY principle and entangling the life cycles of two otherwise unrelated software products together. I have seen a case where insisting on beeing DRY by unexperienced people was one of the core factors where a big project failed. | |
| Nov 21, 2015 at 10:20 | comment | added | gexicide | I disagree. DRY is a very important principle and it should be enforced at almost all costs. If your functions take too many parameters, you should group them into an object. | |
| Oct 2, 2015 at 9:00 | comment | added | Dave | Thanks, Yes I agree, I believe I've tried to accomplish too many things with one common entry point and that is the issue. - 'One ring to rule them all' does not always have good consequences. There's still plenty of opportunity for me to share functions across the requirement, but by introducing code for each specific entry point should make things much easier to understand. | |
| Oct 2, 2015 at 8:57 | vote | accept | Dave | ||
| Oct 1, 2015 at 15:01 | history | answered | David Arno | CC BY-SA 3.0 |