Publishing your research codeYour journal wants your code. Is it ready?

More and more journals ask for the code behind your results, and some reviewers now read it. Here is what the main policies say, and a checklist to get your code ready before you submit.

What journals ask for

Code-sharing policies

A few examples. Policies change and differ between journals: always check your journal's own guidelines. Last checked on 30 September 2026.

Journal	What is required	Since
Nature Portfolio	Custom code central to the main claims must be available to editors and reviewers on request, and a Code availability section is required. Code central to a paper can be peer reviewed.	In force
PLOS Computational Biology	Share publicly any code you created that directly relates to the results in your article, unless you claim an exemption. Refusing to share code may be grounds for rejection.	30 March 2021
PLOS Biology	All author-generated code needed to replicate the findings, including data analysis code, software and algorithms, publicly available at publication.	1 January 2026

Funders are moving in the same direction. In France, the national plan for open science devotes a whole axis to research source code and recommends archiving it in Software Heritage.

Before you submit

A 10-point checklist for research code

You don't need production-grade software. You need code that someone else can find, run, and trust to produce the figures in your paper.

One version, one place. A single repository, not copies on three laptops. The version used for the paper is tagged.
The code matches the methods section. Parameters, thresholds and exclusion rules in the code are the ones described in the paper.
It runs from scratch. Someone who isn't you can install it and run it, following written instructions.
The environment is pinned. Dependencies and versions are listed (requirements file, lock file, container).
Paths are not hard-coded. No C:\Users\me\Desktop\final_data buried in the scripts.
Each figure has a script. It's clear which script produces which figure or table.
The key results are tested. At least one check that the main numbers still come out the same.
Dead code is gone. Abandoned attempts and duplicated functions are removed, not commented out.
It has a licence. Without one, nobody can legally reuse your code.
It is archived and citable. A persistent identifier (for example a Zenodo DOI, or an archive in Software Heritage) and a Code availability statement in the paper.

What it looks like

A code availability statement

Code availability The code used to process the data and produce all figures is available at [repository URL] under the [licence] licence. The version used in this article is archived at [DOI].

Short, precise, and backed by a repository that actually works. That last part is where most of the work is.

Wrote much of your code with an AI assistant? That's fine, and common. It's also where duplicated functions, half-removed attempts and silently changed parameters tend to hide. Points 2, 7 and 8 of the checklist matter even more.

How I can help

From "it works on my machine" to ready to publish

Before submission, or right after acceptance, I go through your code with you: one clean version, a working install, tests on the results that matter, documentation, archiving, and the statement for your paper. A few days of work, sized to fit your lab's budget.

Tell me about your paper