How to write a code availability statement that actually works

Many journals now ask for a code availability statement. Many authors treat it as a box to tick, often on the night before submission. The result is a section that technically exists and practically helps no one.

The statement has one job: let a reader who finishes your paper find the code that produced it, in the version that produced it, with permission to use it. Everything else is detail.

Why does "available on request" fail?

Because requests go unanswered. People change jobs, email addresses expire, laptops get wiped and labs move on. Even with the best intentions, "available from the corresponding author on reasonable request" makes access depend on one person, at one moment, remembering where one folder is.

It also hides the version. A reader who does get a reply may receive whatever the code looks like today, not what it looked like when the analysis was run. If the results do not match, nobody can tell whether the paper or the code changed.

There are honest cases where code cannot be public. We cover those below. But "on request" should be the exception you justify, not the default you reach for.

What does a working statement include?

Five elements, each one short:

1. Where the code is archived. A persistent identifier such as a DOI from Zenodo or a SWHID from Software Heritage. These point to a frozen copy that does not change.
2. Which version. A release tag or commit hash. If you archived a release, the DOI already identifies the version, but naming the tag helps readers who go to the repository.
3. Where development continues. Optional, but helpful: the link to the live repository, so readers can find later fixes.
4. Under what license. Without a license, code is legally "all rights reserved" by default in most places, even if it is public.
5. What else is needed to run it. Data sources, the main dependencies and a pointer to the README or environment file.

What does a good example look like?

Here is a template you can adapt. It fits in a single paragraph.

Code availability: All code used to produce the results in this
paper is archived at Zenodo (https://doi.org/10.5281/zenodo.XXXXXXX),
corresponding to release v1.2.0 of the repository at
https://github.com/example-lab/example-analysis. The code is released
under the MIT License. The computational environment is specified in
environment.yml, and the README describes how to reproduce each
figure from the raw data described in the Data availability section.

Replace the placeholders with your real identifiers. Note what this does well: one archived link, one version, one license, one pointer to instructions. A reader knows exactly where to start.

What if some code cannot be shared?

Sometimes there are real constraints. A model may be licensed from a commercial vendor. Code may embed details of a confidential dataset. An employer may not have cleared release yet. That is fine, as long as you are specific.

A useful restricted statement answers three questions:

• What exactly is restricted? Often it is one component, not the whole pipeline. Share the rest.
• Why? Name the reason: third party license, data protection, pending patent review.
• How can a qualified reader get access? Through a data access committee, a vendor license, a secure environment or a named institutional contact rather than a single person.

Even when code cannot be released, you can usually publish pseudocode, a detailed method description, or a version that runs on synthetic data. Each of those lets a reader check your logic.

Which mistakes should you avoid?

• Linking only to a GitHub homepage. Repositories get renamed, made private or deleted. Archive a copy and cite that.
• Linking to a personal or lab website. These are among the first links to break.
• No license. Public is not the same as open. Readers cannot legally reuse unlicensed code.
• "Code is available in the supplementary material" with a zip of half the scripts. Supplementary files are often unversioned and incomplete. If you use them, make sure they are complete and still archive a copy elsewhere.
• Mixing up code and data. Keep a separate data availability statement. Readers need different things from each.
• Promising future release. "Will be made available upon publication" often never happens. Archive before submission and add the DOI at proof stage if needed. Zenodo lets you reserve a DOI before publishing a record.

When should you write it?

Write it before you submit, not after the editor asks. The act of writing the statement is a useful audit. If you cannot fill in the version line, you do not know which version produced your figures. If you cannot name a license, you have not decided who may reuse your work. Better to find out now than in response to a reviewer.

A practical order of operations:

1. Clean up the repository enough that a stranger can follow the README.
2. Add a license file and a CITATION.cff.
3. Make a tagged release and archive it to get a DOI.
4. Write the statement using that DOI.
5. Ask a colleague to follow the statement from a fresh machine.

That last step catches more problems than any checklist.

How should it connect to the data statement?

Code and data statements are read together, so make them agree. If your code expects a file called survey_2024_clean.csv, the data statement should say where that file, or the raw data it was built from, can be found. If some data are restricted, the code statement should explain which scripts need the restricted inputs and which can run on public data alone. A reader should be able to move from one statement to the other without guessing. Cross reference them explicitly, for example "see Data availability for access to the raw survey files," and use the same names for datasets in both places. Small mismatches here are one of the most common reasons a well intentioned reader gives up.

Does any of this matter to reviewers?

Increasingly, yes. Reviewers who want to check an analysis start with this section. A clear statement saves them time and signals that you expect the code to be read. A vague one invites the question every author dreads: "Could the authors please provide the code?" Better to answer it before it is asked.