Timeline for Could a journal reject an article due to the style or quality of accompanying code?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 7, 2020 at 20:49 | comment | added | mucl | @Backgammon Super sure that there is no unnecessary cleverness hidden due to my limited skills | |
| Aug 7, 2020 at 19:52 | comment | added | Cliff AB | @mucl: "It could just be a lot faster": for a one-off analysis that runs in a reasonable amount of time (i.e., less than a week?), this would never be considered an issue. Readability of the code is much more important (to make sure that the author really analyzed what they thought they analyzed!). Faster is only important if the current speed is "not fast enough to finish". | |
| Aug 7, 2020 at 15:05 | comment | added | Backgammon | Your useful test is: an invented dataset in data.tsv.gz designed to create an obvious result derivable by hand or by inspection of the logic should, in fact, create that result. "Software engineering principles" are not just imaginary things like enforcing LSP or writing visitor patterns, it is also structuring your code (with or without formal methods) in a way such that it is easy to understand for someone looking at the code for the first time so that material logic errors are not covered by unnecessary cleverness or complexity. | |
| Aug 5, 2020 at 13:23 | comment | added | Ian Sudbery |
If your code is df <- read.delim("data.tsv.gz") %>% gather("sample", "outcome") %>% seperate(sample, into=c("rep", "condition")); t.test(outcome ~ condition, data=df), I fail to what a useful test might look like. This is a small exgeration, but much bioinformatics code is not, structurally, that different from this.
|
|
| Aug 5, 2020 at 13:13 | comment | added | Voo | @Ian One of the main goals of "software engineering principles" is to allow code to be testable and correct. One would hope that that would be important. But given the general shoddy practices in many areas about reproducability and using tools correctly I'm afraid you're quite right in practice. That's how we end up with things like 1 in 5 of genetics papers containing errors due to excel reformatting. | |
| Aug 4, 2020 at 17:31 | comment | added | Ian Sudbery | Getting people to publish code in biology is a real problem, and this quesiton ere illustrates why. People are scared to let others see the code. The code generally run once code - that is it will never be useful for anyone else ever, and will almost certainly never be run again, but acts a log of how the analysis was conducted. It generally doesn't make sense to apply software engineering principles to it. | |
| Aug 4, 2020 at 17:05 | comment | added | user2768 |
@mucl E.g., while (*s++ = *t++);, for an explanation, see: stackoverflow.com/a/7483682/3664487
|
|
| Aug 4, 2020 at 15:59 | comment | added | Jon Custer | Frankly, most code is bad even by professional software developers. And, writing code to analyze/simulate/take data has fewer demands to be 'good' and more to be 'good-enough'. | |
| Aug 4, 2020 at 15:13 | comment | added | mucl | yes. Bc obviously my results do depend on my code. However, as I said above, I'm confident it works so far. It could just be a lot faster, e.g. I'm not used to creating loops in r. | |
| Aug 4, 2020 at 14:44 | comment | added | Buffy | @mucl, an example of what? Bad code? | |
| Aug 4, 2020 at 14:16 | comment | added | mucl | could you give me an example? | |
| Aug 4, 2020 at 14:10 | history | answered | Buffy | CC BY-SA 4.0 |