Timeline for Why is DRY important?
Current License: CC BY-SA 3.0
38 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 19, 2015 at 2:40 | comment | added | JeffO | "I'm unlikely to need to edit this again any time soon." If that's the case, then why worry about following any best practices for programming? Experience tells us there is a good chance you will eat those words. | |
| Feb 20, 2015 at 20:53 | answer | added | supercat | timeline score: 1 | |
| Sep 2, 2014 at 14:23 | comment | added | Incognito | Wow Jim, do you talk down to everyone on the internet? | |
| Aug 30, 2014 at 3:53 | comment | added | Jim Balter | "Strongly depends if doStuffX depends on each other or not." -- DRY has nothing to do with whether they depend on each other, but rather whether they duplicate decisions. | |
| Aug 30, 2014 at 3:48 | comment | added | Jim Balter |
That you said nothing about the relationship between a, b, c, d suggests that you don't understand enough about DRY to ask a meaningful question about it. The only thing repeated here is function doStuff { }, but DRY is not at all about repetition of syntax, it's about the repetition of policy and method.
|
|
| Jul 21, 2014 at 11:29 | comment | added | AturSams | @WayneM Less work is the path of the light side of the Source. Duplication creates more work for everyone involved. The list 1-7 in my answer is the kind of attitude I expect candidates to express in interviews if they want to work together. | |
| Jul 21, 2014 at 11:20 | answer | added | AturSams | timeline score: 0 | |
| Mar 6, 2012 at 23:53 | comment | added | ford | "Hope is not a design pattern" | |
| S Feb 17, 2012 at 12:18 | history | notice removed | CommunityBot | ||
| S Feb 17, 2012 at 12:18 | history | unlocked | CommunityBot | ||
| Feb 16, 2012 at 12:15 | history | notice added | ChrisF♦ | Comments only | |
| Feb 16, 2012 at 12:15 | history | locked | ChrisF♦ | ||
| Feb 16, 2012 at 7:57 | answer | added | Simon | timeline score: 1 | |
| Feb 16, 2012 at 3:51 | comment | added | dukeofgaming | Adding to the other replies, ask that to yourself whenever you are maintaining someone else's code. | |
| Feb 16, 2012 at 2:00 | answer | added | James Anderson | timeline score: 0 | |
| Sep 1, 2011 at 17:55 | answer | added | HLGEM | timeline score: 2 | |
| Sep 1, 2011 at 16:18 | answer | added | Pacerier | timeline score: 1 | |
| Aug 26, 2011 at 12:01 | answer | added | Joh | timeline score: 3 | |
| Aug 25, 2011 at 13:48 | vote | accept | Incognito | ||
| Aug 25, 2011 at 2:40 | answer | added | John Tobler | timeline score: 1 | |
| Aug 24, 2011 at 21:59 | comment | added | CaffGeek | As a general rule, if you copy-paste in code, assume you just did something wrong, and really think if you should be copy-pasting or refactoring properly. | |
| Aug 24, 2011 at 16:53 | history | edited | Thomas Owens♦ |
edited tags
|
|
| Aug 24, 2011 at 13:43 | comment | added | Incognito | @Wayne I felt a great disturbance in the source, as if millions of programmers suddenly cried out in terror. | |
| Aug 24, 2011 at 13:40 | comment | added | Wayne Molina | "Less work" is the path to the Dark Side - easier at first and harder later. Once you start down that path, forever will it dominate your destiny... | |
| Aug 24, 2011 at 12:27 | answer | added | Giorgio | timeline score: 7 | |
| Aug 24, 2011 at 9:57 | comment | added | David Heffernan | If you can't answer this yourself, you need to get some more real world experience of development and maintenence. | |
| Aug 24, 2011 at 7:45 | comment | added | user1249 | Strongly depends if doStuffX depends on each other or not. | |
| Aug 24, 2011 at 7:40 | answer | added | Steven Jeuris | timeline score: 5 | |
| Aug 24, 2011 at 7:08 | comment | added | Falcon | I think you can pretty much sum it up with: A single point of change is easier to maintain. | |
| Aug 24, 2011 at 3:40 | history | tweeted | twitter.com/#!/StackProgrammer/status/106209312304668672 | ||
| Aug 24, 2011 at 2:31 | answer | added | bedwyr | timeline score: 14 | |
| Aug 24, 2011 at 2:06 | answer | added | haylem | timeline score: 18 | |
| Aug 24, 2011 at 2:06 | comment | added | 9000 | "I'm unlikely to need to edit this again any time soon" — you may hope, but most probably you're making a mistake here. And if you're going to work on that code again, but not so soon, it will only make things worse; you will forget where duplicates are, and duplicates will grow subtle but treacherous discrepancies. "Write as if the person who will maintain your code is a dangerous maniac that knows where you live", to quote the classics. | |
| Aug 24, 2011 at 1:59 | answer | added | Alex | timeline score: 8 | |
| Aug 24, 2011 at 1:58 | answer | added | Doug T. | timeline score: 126 | |
| Aug 24, 2011 at 1:55 | answer | added | John | timeline score: 51 | |
| Aug 24, 2011 at 1:54 | comment | added | Daniel Little | because dry is still faster when you do it right, also what if you made a mistake in a. that effects all the others | |
| Aug 24, 2011 at 1:48 | history | asked | Incognito | CC BY-SA 3.0 |