Timeline for The Don't Repeat Yourself (DRY) principle in documentation
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 14, 2021 at 21:23 | audit | First posts | |||
| Jul 14, 2021 at 21:23 | |||||
| Jun 30, 2021 at 15:12 | comment | added | Doc Brown | @Laiv: that's not my point. These examples are not showing cases where DRY code was made repetitive for optimization purposes. | |
| Jun 30, 2021 at 14:28 | comment | added | Laiv | @DocBrown for this Documentation is random access and because sometimes, the implementation details matter. For example, isEmpty(). This's the kind of function where implementation details matter because conditions vary from type to type. isEmpty(array) and isEmpty(String) have different semantics. For example, how many times have you wondered if "null" is checked as "empty" or it cast an exception? And whitespace? Does the method cast trim before checking it out? And tabs? What about collections? What makes a map to be empty? its length? the null entries? Etc. | |
| Jun 27, 2021 at 12:02 | comment | added | BreakingGnus | "If your map doesn't match the terrain, trust the terrain." (or change it) | |
| Jun 25, 2021 at 6:59 | comment | added | Doc Brown | This point of view does not convince me. If code is implemented in a DRY fashion or not is an implementation detail from the APIs point of view. For example, if code which was once DRY, with a non-repetitive documentation, is made repetitive for the sole purpose of optimization, why should the documentation then be changed? | |
| Jun 24, 2021 at 14:37 | history | answered | Karl Bielefeldt | CC BY-SA 4.0 |