Following on from our sponsorship of the Guide to Reproducible Code in Ecology and Evolution and our collaboration with rOpenSci, we have now released a new policy on publishing code. The main objective of this policy is to make sure that high quality code is readily available to our readers.
We’ve set out four key principles to help achieve this, as well as explaining what code outputs we publish, giving some examples of things that make it easier to review code, and giving some advice on how to store code once it’s been published. Below is a summary of some highlights of the policy, but you can find it in full on the Methods in Ecology and Evolution website.
Our Four Key Principles
Quality We want to make sure that readers and users can have confidence that code published in the journal is of high quality and that there is evidence of high standards of code preparation. Unfortunately, this can’t include extensive testing (this is incredibly time-consuming for Reviewers and Editors), but it will involve look for evidence of good coding practice.
Usability Code needs to be usable – not a particularly revolutionary statement. Readers should be able to implement the methods that go along with any code readily. This includes both the implementation and the platform. Where possible, we discourage the use of proprietary software in favour of ones that respect established standards for software freedom. The implementation should include documentation and examples with benchmarking data (see below) where possible.
Accessibility As with published articles, a version of record is necessary for published code: this should be the exact version of the code described in the journal and able to replicate all of the results presented. We know that code evolves and encourage the use of platforms that permit updating with version control.
Functionality Functionality needs to be novel and add to what is already available. We can’t consider re-implementations of existing methods, except where they take advantage of new methods permitting significant computational gains.
Ensuring Quality through Peer Review
As mentioned above, we can’t ask Reviewers or Editors to check code line by line – it simply isn’t feasible. But we can still ensure the quality of the code that we publish by checking for good coding practices. The overall philosophy is that robustly written code will be easier for reviewers to review and authors to revise. The following is not an exhaustive list of good practices, but these are four practices that we recommend:
Benchmark Data These should be included and where possible worked through from first principles as well as using code. For example, code may implement a new statistical method: it would be ideal to provide a worked example in the text or appendix of a paper that is then replicated by running the code.
Unit Testing While it may not be suitable for basic code, for more complex applications unit-testing is a best-practice approach for testing components and demonstrating that they perform as expected.
Documentation Thorough documentation of code will help readers, reviewers and users to understand the overall structure of code or a package.
Version Control Clear history of code with revisions tracked and documented will make clear how bugs are fixed and how subsequent versions of code relate to that originally submitted.
Sharing and Storing Code
We recommend that code is stored in a repository that allows for version tracking and is able to assign a DOI. This ensures that there is a permanent version of the code that is discussed in a published article and allows readers to easily access the most up-to-date version of the code whenever they try to access it.
All code submitted to Methods in Ecology and Evolution must include a fully open source software license. This is because current copyright law prevents code sharing by default, thus necessitating a license explicitly allowing code sharing and reuse.
To find out more read Rob Freckleton’s Editorial on our policy on publishing code in the January issue of the journal. You can also find the full policy here.