Code and results6 min readBy Saradha R, Senior Research AnalystPublished 2026-10-24

How to share research code so others can reproduce your results

Research code is reproducible when another person can follow your README, install the listed software versions, run one command and get the same tables and figures. To get there, organise files by task, record package versions and random seeds, save outputs with file paths, add a licence, archive a release with a DOI, and write a code availability statement.

Journals and funders increasingly ask for code, and reviewers increasingly try to run it. Code that works only on the author’s laptop wastes everyone’s time, including yours when you return to it a year later. This guide gives a short checklist you can finish in an afternoon.

What does reproducible mean?

Reproducible means that someone with your code and your data (or the same type of data) can obtain your reported results. It is not the same as replicating the study with new data. Many fields also use the FAIR principles: findable, accessible, interoperable and reusable.

A folder layout that works

Splitting the code by task makes it easier to read, test and review. A reviewer who wants to check one result can open one file.

Record the environment and the seeds

• List package versions (for Python, pip freeze or an environment file; for R, a lock file). Name the language version too.
• Set random seeds at the start, and report them. If the result changes with the seed, run several seeds and report the spread.
• Say what hardware you used if it matters, for example a GPU.
• Avoid paths that only exist on your computer. Use relative paths.

If installation is difficult, consider a container such as Docker, and say so in the README.

Handle data carefully

Share data only if you may. For private or licensed data, share a small synthetic or sample set, describe the format, and say how others can request access. Never upload personal or confidential data.

Write a README that gets someone running

1. One paragraph: what the code does and which paper it belongs to.
2. Requirements: language version, packages, any hardware.
3. Install: the exact commands.
4. Data: where it goes and how to get it.
5. Run: the exact command and what to expect, with the time it takes.
6. Outputs: where results are saved and which table or figure each file matches.
7. Citation: how to cite the paper and the code.
8. Contact: who to ask.

Tip Test the README on a clean folder or another computer. If you stumble, a reader will.

Archive it and say so in the paper

Template / example

Code availability: The code used to produce the results in this paper is available at [DOI or URL], version [x.y], under the [licence] licence. Instructions to reproduce Tables 2 and 3 are in the README.

A final checklist

• I can run the code from a clean install by following the README.
• Package versions and seeds are recorded.
• Every figure and table in the paper maps to a script and an output file.
• There are no private paths, keys or personal data in the repository.
• A licence is included.
• A release is archived with a DOI, and the paper has a code availability statement.

A minimal README you can copy

Template / example

# Project title Code for the paper [citation]. ## Requirements Python 3.11. Install packages with: pip install -r requirements.txt ## Data Place the dataset in data/ (see data/README for the source and the file format). ## Run python main.py The run takes about [time] on [hardware]. Results are saved in results/. ## Outputs results/table2.csv corresponds to Table 2. results/fig3.png corresponds to Figure 3. ## Licence and citation [Licence]. Please cite [paper] and this code release [DOI].

Add a few tests

A small test that checks a function on a tiny input catches many mistakes and tells a reader the code works. You do not need a large test suite. Two or three tests on the data loader, the metric and one method are a good start. Add a note about how to run them.

Where a tool can help

In EasySeer, code generation writes the code as separate files, one per task, plus a main program with a screen to run everything, and a readme and requirements file. You open each file in the viewer, read it and change it. Code execution then runs it on your computer with Python and saves graphs, result tables and sample outputs with their file paths, plus a full log.

Generated code can contain mistakes, so reading it is part of your job. EasySeer reports weak results as they are and does not tune results to reach a target or invent numbers. Very large datasets may need more time, and some specialised libraries or hardware may need setup on your computer.

See code executionSee code generationRead: read the code and results

Questions

What makes code reproducible?

A clear README, recorded package versions and seeds, a single run command, and saved outputs that match the paper’s tables and figures.

Do I have to share my code?

It depends on the journal, funder and field. Many ask for a code availability statement, even if the code cannot be shared, so you explain why.

Which licence should I choose?

Permissive licences such as MIT or Apache 2.0 allow wide reuse. Your institution or funder may have rules, so check before you publish.

What if my results change a little each run?

Fix the seeds, run several seeds and report the average and spread. Say clearly which parts are random.

Should I share the trained models or data?

Share them if the licence and privacy rules allow it, and say where. If not, explain what others can request and how.

Keep reading

Sources

Checked on 2026-10-24. Policies change, so read the current version before you submit.

• Springer Nature: how to share your research code openly
• Zenodo
• FAIR principles (GO FAIR)

Published 2026-10-24. Last updated 2026-10-24.