Right, that's what I meant by code review in the first paragraph: internal review within the research group.
Agreed also that they should use version control and other standard practices, etc.
Agreed also that they should use version control and other standard practices, etc.
So, there's literally nobody else on these projects who could conduct a code review. This also sort of provides a disincentive towards using VCS even though it's so obviously a good idea if you're the only person contributing code—I've talked with programmers about this before and the response is "why bother?" unfortunately.
Ah, I took it as code review during the peer review process (i.e. from reviewers). Unsure how realistic this would be.
Unfortunately, this would make the already laborious process of peer review even longer and require more work. Given the reality of academia today (publish vs perish), not to mention the added work of preparing even well structured, version controlled code (which is not, in my experience common) for publishing, most researchers would not opt-in (or support) something which would make publishing more difficult.
Who cares? If researchers are producing crap to get published, why should we mind if they stop producing that crap when journals raise the standards of publication?