Welcome

Best practice for code sharing

Code that still runs when someone else opens it

Much of the analytical code behind published papers is never shared, and some of what is shared cannot readily be used or run. This wiki sets out four practices to apply before you submit a project. Together they make analytical code more transferable, available, documented and annotated.

A cartoon wizard casting a spell, saying TADA!

What this wiki is

Sharing code supports transparency and computational reproducibility, and journal policies increasingly require it (Ivimey-Cook et al. 2025). Even so, few papers in the field share code: reported rates range from roughly 5% to 35%, and code sharing still lags behind data sharing (Ivimey-Cook et al. 2025). And when code is shared, it often fails to run. Of over 9,000 R files archived in the Harvard Dataverse, 74% failed to complete without error, and 56% still failed after automated cleaning (removing local file paths and fixing library installation and loading). A study of species distribution and abundance papers abandoned its reproducibility assessment because 93% of scripts either did not run or ran with errors.

One reason is that researchers are rarely taught how to archive analytical code. The resources that do exist are written largely for software developers, not for someone preparing a one-off analysis of a single dataset.

TADA (Transferable, Available, Documented, Annotated) is a set of simple guidelines aimed at that gap. This wiki expands them into a working reference and adds the practices that go with them: metadata, licences, repository choice, the data and code quality control guidelines from SORTEE (the Society for Open, Reliable, and Transparent Ecology and Evolutionary Biology), and code review.

The four principles

T Transferable Anyone can open your file and run it on their own machine, without converting or editing it first.

A Available The code is publicly archived somewhere immutable, with a persistent identifier (a DOI) that is cited in the paper.

D Documented A README describes the files, the software environment, the licence, and where the data live.

A Annotated Comments inside the code say what each chunk does, why it is needed and which result in the paper it produces.

TADA is deliberately a minimum standard. Analytical code is usually written for one dataset and one study, so it needs to be a transparent, reproducible record of that analysis, not reusable software. TADA is pitched at that level and maps onto the FAIR principles (Findable, Accessible, Interoperable, Reusable).

How to use this wiki

If you want to… Go to
Get code ready to submit Start here
Understand TADA and how it maps to FAIR TADA at a glance
Work through one principle at a time Transferable, Available, Documented, Annotated
Write a README or pick a licence Documented
Choose a repository Available
Decide which data to share, in what format and with what metadata Data & code sharing
Know what a journal’s data editor will check The SORTEE guidelines
Set up or run a code review Code review
Find guides, tutorials and papers Further reading
Look up a term such as DOI, README or licence Glossary
Add a page to this wiki Contribute
Find the full details of anything cited References

Who this is for

Researchers at any level of coding experience who need to share the code behind a paper. The examples use R and Python, languages widely used in ecology and evolutionary biology. The principles also apply to workflow languages such as Snakemake, compiled languages such as C++, and other disciplines.

You do not need to know Git, Docker or unit testing to follow this wiki. Where those tools help, they are mentioned as optional.

Where the guidance comes from

This wiki draws on three sources, linked by DOI below.

  • Ivimey-Cook, E. R., Culina, A., Dimri, S., Grainger, M. J., Kar, F., Lagisz, M., Moran, N. P., Nakagawa, S., Roche, D. G., Tattan, S., Sánchez-Tójar, A., Windecker, S. M., & Pick, J. L. (2025). TADA! Simple guidelines to improve analytical code sharing for transparency and reproducibility. EcoEvoRxiv. https://doi.org/10.32942/X2D93K (preprint; not yet peer reviewed).
    Source for the four TADA principles and the Transferable, Available, Documented and Annotated chapters.

  • Pick, J. L., Allen, B. J., Bachelot, B., Bairos-Novak, K. R., Brand, J. A., Class, B., Dallas, T., D’Amelio, P. B., Fenollosa, E., Fernández-Juricic, E., Gomes, D. G. E., Grainger, M. J., Guillemaud, T., John, C., Krasnow, R., Lagisz, M., Lequime, S., Maynard, D. S., Nakagawa, S., O’Dea, R. E., Paquet, M., Petitjean, Q., Sánchez-Tójar, A., van Dis, N. E., Wilson, L. A. B., & Ivimey-Cook, E. R. (2026). The SORTEE guidelines for data and code quality control in ecology and evolutionary biology. Peer Community Journal 6: e20. https://doi.org/10.24072/pcjournal.687
    Source for the SORTEE guidelines chapter and most of Data & code sharing.

  • Ivimey-Cook, E. R., Pick, J. L., Bairos-Novak, K. R., Culina, A., Gould, E., Grainger, M., Marshall, B. M., Moreau, D., Paquet, M., Royauté, R., Sánchez-Tójar, A., Silva, I., & Windecker, S. M. (2023). Implementing code review in the scientific workflow: Insights from ecology and evolutionary biology. Journal of Evolutionary Biology 36: 1347–1356. https://doi.org/10.1111/jeb.14230
    Source for the Code review chapter.

Full details, plus everything else cited, are in References.

Where this wiki adds practical detail beyond the source papers, such as a worked README, a repository comparison table or a reviewer’s script, that material is shown in a Wiki Tip box, so you can tell it apart from the findings of the papers.