Timeline for Undoing "fixes"
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 4, 2017 at 6:19 | answer | added | Rhys Johns | timeline score: 0 | |
| May 4, 2017 at 6:18 | comment | added | Martin Maat | If your insight/understanding of the code has grown and you realize that some of your initial attempts did not make the code behave any better or make it easier to understand or if you find it sort of deviates from the original design, is just not helpful, of course you should revert or improve it to the best of you ability at that time. If you know it is just noise you should removed it in order to avoid confusion for the next developer who is to get his head around it. | |
| May 4, 2017 at 3:01 | comment | added | Criticizing Israel not allowed | What are these "attempted fixes"? Are they changes to the program that don't improve it in any way? If so then why would you put them in the program? Source control makes it easy to throw away failed changes. | |
| May 3, 2017 at 22:22 | answer | added | user232573 | timeline score: 3 | |
| May 3, 2017 at 18:13 | answer | added | Frank Hileman | timeline score: -2 | |
| May 3, 2017 at 16:45 | comment | added | Ewan | @Tobi yeah, if you find a bug, write a test that fails and then fix it is good practice | |
| May 3, 2017 at 16:34 | review | Close votes | |||
| May 8, 2017 at 3:03 | |||||
| May 3, 2017 at 16:29 | answer | added | Ewan | timeline score: 4 | |
| May 3, 2017 at 16:28 | comment | added | Vincent Savard | It doesn't have to be a unit test, and no, not everyone does it, but they should. I consider that writing the test ensures that I understand how the issue happens, and when I write it beforehand, I can be confident that the code I wrote fixes the issue. | |
| May 3, 2017 at 16:19 | comment | added | Tobi | Do people really write unit tests per bug? | |
| May 3, 2017 at 16:18 | comment | added | Vincent Savard | You don't exactly "attempt" fixes. You usually try to add automated tests that replicate the bug, then write code until those tests no longer fail. You can then try to replicate the bug manually in app to ensure it no longer happens. At this point, you should be confident you solved the issue, and if another one arise, there's no reason to remove code that fixed an actual issue (as you detected it in the tests). | |
| May 3, 2017 at 16:10 | history | asked | Tobi | CC BY-SA 3.0 |