Timeline for DRY Violation for Logical Code Organization and Readability
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2020 at 6:50 | answer | added | gnasher729 | timeline score: 1 | |
| May 19, 2020 at 11:37 | history | edited | Dragonsheep | CC BY-SA 4.0 |
added 264 characters in body
|
| May 19, 2020 at 11:31 | answer | added | Ralf Kleberhoff | timeline score: 2 | |
| May 19, 2020 at 11:24 | history | edited | Dragonsheep | CC BY-SA 4.0 |
added 85 characters in body
|
| May 19, 2020 at 10:52 | history | edited | Dragonsheep | CC BY-SA 4.0 |
added 282 characters in body
|
| May 19, 2020 at 5:46 | comment | added | Rik D | @Filip Milovanović why not post it as an answer? | |
| May 19, 2020 at 4:53 | comment | added | Filip Milovanović | DRY is not an end in itself. Don't overemphasize organizational consistency. It's more important to consider if both versions of D will have to be changed in the same way (if every change will have to be done in two places). If that's something you can already tell or reasonably expect, then it's better to DRY out the code and have one D() method. If they are really going to evolve independently or if you'll end up with a bunch of if statements in that method, then it's better to split them. Another option to consider is object polymorphism in place of the two functions. | |
| May 19, 2020 at 0:22 | history | asked | Dragonsheep | CC BY-SA 4.0 |