How to Write a Code Availability Statement (With Templates)

A code availability statement is a short, required section telling readers whether the code behind your results exists, where it lives, and on what terms they can get it. Most journals in computational fields now mandate one, and most authors write it in thirty seconds at submission without realising it is the section an editor can reject the paper over.

This guide covers what the statement must say, where it goes, the templates for each situation, and the mistakes that get manuscripts returned.

What a code availability statement has to say

Nature Portfolio’s requirement is the clearest formulation: the section must indicate “whether and how the code or algorithm can be accessed, including any restrictions to access”.

Three components, then:

• Whether custom code exists for this paper at all.
• Where it is — a specific, persistent location, not “available on GitHub”.
• On what terms — the licence, and any restriction that stops a reader simply downloading and running it.

It sits as a separate section after the data availability statement and before the references. It is not a subsection of the methods, and it is not the same as the data statement — a point covered below, because conflating them is the single most common error.

What counts as “custom code”

The obligation attaches to code that is central to the conclusions of the paper. That is the test, and it is narrower than “everything you typed”.

• Covered: analysis scripts you wrote, a model you implemented, a simulation, a pipeline that produced the reported numbers, bespoke pre-processing that materially shapes the result.
• Not covered: standard published software used as intended — SPSS, R with public packages, MATLAB toolboxes, commercial instrument software. You cite these; you do not deposit them.

The grey zone is a short script that glues standard tools together. If someone could not reproduce your numbers without it, it is central, and it should be deposited.

Where to put the code — and why GitHub alone is not enough

This is the requirement authors most often miss. Springer Nature states it directly: code should be deposited in a repository that assigns a permanent identifier, and a GitHub link on its own is insufficient.

The reason is straightforward. A GitHub repository can be renamed, made private, force-pushed over, or deleted entirely, and the link in your paper then points at nothing. A DOI does not move.

The standard practice:

1. Develop in GitHub (or GitLab) as normal.
2. Archive the exact version used for the paper to a DOI-minting repository — Zenodo and Code Ocean are the two named in publisher policies. Zenodo’s GitHub integration does this on release with no manual upload.
3. Cite the archived version in the reference list, the same as any other work.
4. Link the live repository too if you want readers to follow ongoing development. Both, not either.

Attach an open-source licence approved by the Open Source Initiative — MIT and BSD for permissive, GPL where you want derivatives kept open. Code with no licence is, by default, not reusable at all, whatever your intentions were.

Templates for each situation

Adapt these; every one of them needs a real location substituted in.

Code openly available

The analysis code supporting this study is openly available in Zenodo at https://doi.org/10.XXXX/zenodo.XXXXXXX, released under the MIT licence. Development continues at https://github.com/<org>/<repo>.

Code available with restrictions

The code supporting this study is available from the corresponding author on reasonable request. It cannot be released publicly because it contains components licensed from <third party> under an agreement that prohibits redistribution.

State the reason. “Available on request” with no explanation is the version editors push back on, and the version readers have learned to distrust.

No new code

No custom code was generated for this study. All analyses were performed in R 4.3.1 using the publicly available packages cited in the Methods.

Code released after an embargo

The code will be deposited in Zenodo and made publicly available under the MIT licence on publication. It is available to editors and reviewers during peer review at <private link>.

What happens during peer review

Two things catch authors out.

First, sharing code with editors and reviewers during review is expected, and at some journals mandatory, even where public release happens later. A private repository link or an anonymised archive deposit satisfies this.

Second, and more seriously: editors reserve the right to decline a paper if code central to the conclusions is unavailable. Nature Portfolio states this explicitly. A code availability statement that amounts to a refusal is not a neutral administrative choice — it is grounds for rejection at journals with a strong policy.

There is a genuine exception, and it is narrow: where releasing code would compromise participant privacy or breach a legal agreement. Even then, the conditions of availability still have to be stated.

Making the code usable once someone finds it

A DOI gets a reader to the code. Whether they can run it is a separate problem, and it is where most deposited research code fails.

Four things carry most of the weight:

• A README that states what the code does and how to run it — the entry point, the expected inputs, and which script produces which figure or table. This is the single highest-value file in the archive.
• Pinned dependencies. A requirements.txt, environment.yml, renv.lock or equivalent, with versions. “Python 3” is not a specification; an environment that resolved in 2024 often will not resolve today.
• Fixed random seeds where results depend on them, stated in the code rather than left to the default.
• A small worked example that runs in minutes on data you are allowed to share. If the real dataset is restricted, a synthetic sample lets a reader confirm the pipeline executes even when they cannot reproduce your exact numbers.

None of this is required by the statement itself. All of it determines whether the statement is true in any useful sense.

Code availability vs data availability

They are separate statements answering separate questions, and most journals require both.

	Data availability	Code availability
Question answered	Where are the observations?	How were they turned into results?
Typical repository	Discipline repository, Dryad, figshare	Zenodo, Code Ocean
Licence type	Data licence, often CC BY or CC0	Open-source software licence
Common restriction	Participant confidentiality	Third-party or commercial licensing

Having open data and closed code makes a result unverifiable just as surely as the reverse. Our guide to data availability statements covers the other half.

Policies differ — check yours before you write

The requirement is not uniform, and the differences are the kind that cause a return at editorial check rather than a rejection.

• Strictest: Nature Portfolio and Springer Nature journals — a statement is mandatory for original research developing new code, a permanent identifier is required, GitHub alone is not accepted, and code may have to be supplied during review.
• Middle: many society and field journals require a statement but accept a repository link without insisting on a DOI.
• Lightest: some journals ask only that availability be mentioned somewhere in the methods.

Book chapters are generally encouraged rather than required to share, even at publishers whose journals mandate it.

Two minutes in the instructions for authors tells you which regime you are in. The safest approach is to write to the strictest standard regardless — a DOI-archived, licensed release satisfies every policy, and costs nothing extra once you have done it once.

Five mistakes that get statements returned

1. A bare GitHub URL. No DOI, no version, no licence. The most common rejection at editorial check.
2. Linking the repository but not the version. A reader arriving two years later gets whatever is on the main branch, not what produced your figures. Archive a release and cite it.
3. No licence. Unlicensed code is legally unusable, however public the repository.
4. “Available on reasonable request” with no reason and no intention. Editors increasingly treat this phrasing as a restriction requiring justification rather than a neutral default, and a statement that promises access without a stated reason invites a query at editorial check.
5. Writing it at submission rather than while working. Reconstructing which version produced which figure, months later, is the part everyone underestimates.

Before you submit

• Custom code central to the conclusions is identified.
• The exact version used is archived and has a DOI.
• An OSI-approved licence is attached.
• The archived version is cited in the reference list.
• The statement names the location, the licence and any restriction — with a reason.
• The statement sits after the data availability statement and before the references.
• Reviewers have a route to the code during review.
• You have checked the target journal’s own wording; policies differ in the detail.

Frequently asked questions

Do I need one if I used only standard software? Usually yes — a statement saying no custom code was generated. Silence reads as an omission.

Does a GitHub link ever suffice? At some journals, yes. At Springer Nature and Nature Portfolio titles, no — a permanent identifier is required.

What licence should I choose? MIT if you want maximum reuse, GPL if you want derivatives to stay open. Check whether your institution or funder mandates one.

Can I keep the code private and still publish? Sometimes, with a stated reason. At journals with strong policies, code central to the conclusions being unavailable can mean rejection.

What if the code is not mine to release? Say so, name the constraint, and describe what you can provide — pseudocode, parameters, or a worked example is better than nothing.

What to take from this

The statement is short, but it is a claim about whether your result can be checked. Archive the version you actually used, give it a DOI and an OSI-approved licence, cite it properly, and state any restriction with its reason. Write it while the work is fresh rather than at submission, and it takes minutes instead of an afternoon of forensic git archaeology.

The authoritative version of these requirements is in the Nature Portfolio reporting standards and availability policy.

Related reading: data and code sharing best practices and research software as scholarly output.