Timeline for Should I share my horrible software?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 24, 2015 at 4:03 | comment | added | Matthew Read | Sharing failed attempts is different from mixing broken code into the working code, which doesn't accomplish anything except confuse and prevent understanding. | |
| Jan 25, 2015 at 16:08 | comment | added | Blair MacIntyre | If the code is an implementation of a research paper, and he tried to implement it different ways, my assumption is that the solution is non-obvious. In research, someone else might see the working code and think "I could do this better this way" which might be one of the ways the author tried first. We do poorly in CS at sharing our failures, which leads to lost work sometimes. That's my point. Whether it's a good choice in_this_ case can't be known without seeing the code, but I know plenty of other profs who share this view | |
| Jan 25, 2015 at 16:01 | comment | added | Piotr Migdal | I don't see how a failed code can help except for obfuscating the working code (unless errors are clear and e.g. "much simpler code, but works only for positive entries"). But what is good to make comments (e.g. "it would be tempting to use arrays, but they won't work for non-unique entries"). | |
| Jan 23, 2015 at 18:36 | comment | added | David Z | @coredump Saying what you tried in the sense of including failed code is good advice when you're asking for help, but not for writing the program itself. | |
| Jan 23, 2015 at 13:21 | comment | added | coredump | @DavidZ Sorry, but "Say why they failed, and what you tried" is a good advice, IMHO. If your code is messy and/or if you are not accustomized to software engineering practices, please leave it as-is and comment as much as you can. Removing useful informations could make things virtually incomprehensible. I've seen this happen ;-). Okay, so maybe there is a middle-ground between showing all the horrible things that were attempted and leaving useful traces. I think "I would clean it up a little" is also a good advice. | |
| Jan 23, 2015 at 10:56 | comment | added | David Z | @coredump It can make the entire program virtually incomprehensible. I've seen this happen. If you don't use VC, start using it. The only way I could support a recommendation not to remove failed attempts is if you're forbidden from putting the code in VC for some reason which I can't imagine, and it's essential to see the previous code in order to understand what the current code does (which probably means the current code is bad too, though I admit that exceptions may exist). | |
| Jan 23, 2015 at 10:51 | comment | added | coredump | @DavidZ On the contrary, show it. If you use version control, people can see previous variations of your work, which is far from being useless. But if like here you don't use VC, then don't remove failed attempts. Put them in another file with appropriate comments. How harmful could it be? | |
| Jan 23, 2015 at 9:57 | comment | added | David Z | I can't endorse leaving in failed attempts. You should use version control instead. Including brief comments that explain why the initial attempt failed is fine, but including the actual failed code may be actively harmful. | |
| Jan 22, 2015 at 21:32 | review | First posts | |||
| Jan 22, 2015 at 22:06 | |||||
| Jan 22, 2015 at 21:31 | history | answered | Blair MacIntyre | CC BY-SA 3.0 |