Why journals should require code

A modern paper often rests on thousands of lines of code that nobody outside the author team has seen. The methods section describes the analysis in a few paragraphs. The code is the analysis. When journals require one but not the other, they publish an incomplete method and call it complete.

This is not a radical position. Many journals already have code policies of some kind. The question is how strong they are and whether they work.

Why should code be treated as evidence?

Because results come out of it. Every filter, transform, model and plot in an analysis is implemented in code, and every one of those steps can contain a mistake. Mistakes in code are not rare or exotic. They are ordinary, made by careful people, and they can change conclusions.

A methods section can describe intent. Only the code shows what actually ran. Reviewers and readers who want to check a result, extend it or reuse it need the code. Without it, "reproducible" means "trust us."

What are the arguments against, and do they hold up?

• "Authors will be embarrassed by their code." Probably, and that is fine. Shared imperfect code is more useful than private perfect code. Policies can say explicitly that code does not need to be polished.
• "It adds burden." Some, mostly once. Archiving a release takes minutes. The bigger cost is organizing code well enough to share, which also makes it more likely to be correct.
• "Some code cannot be shared." True. Licensed tools, sensitive data, legal restrictions. Good policies include exceptions with a clear process.
• "Reviewers cannot check it." Often true today. But availability is valuable even without review. Readers, replicators and future students can check what reviewers did not.
• "Competitors will take it." Sharing after publication mostly helps people build on your work, with citation. Archived code with a DOI is citable, which turns reuse into credit.

What levels of policy exist?

Journal code policies sit on a ladder. The TOP Guidelines from the Center for Open Science describe a similar progression for code transparency. In plain terms:

1. Encourage. The journal says sharing code is good practice. This costs nothing and changes little on its own.
2. Require a statement. Every paper must include a code availability statement, even if it says the code is not available and why. This makes the choice visible, which already shifts behavior.
3. Require deposit. Code used to produce the results must be archived in a trusted repository with a persistent identifier and an open license, unless an exception applies.
4. Review or verify. Editors or reviewers check that the code exists, is documented and runs, and in the strongest form, that it reproduces key results before publication.

Each step up the ladder is worth taking. A journal that moves from encourage to require a statement has done something real.

What does a good policy say?

Vague policies get vague compliance. A good one answers these questions in plain language:

• What is covered? All custom code needed to reproduce the reported results, including data cleaning and figure generation, not just the "main" model.
• Where should it go? A repository that issues persistent identifiers, such as Zenodo, Figshare, OSF or a discipline specific archive, with Software Heritage identifiers accepted. A bare link to a personal website or a code hosting page is not enough on its own.
• When? At submission for review, with a final archived version at acceptance.
• Under what license? An OSI approved open source license, or a clear statement if the code cannot be openly licensed.
• What documentation? A README with instructions and a record of dependencies and versions.
• What are the exceptions? Third party licenses, sensitive data, legal restrictions, with a requirement to explain the restriction and an access route for qualified readers.
• How is it cited? Software should be cited in the reference list, following the FORCE11 Software Citation Principles.

It should also say what code does not need: it does not need to be elegant, general purpose or maintained forever.

How can journals support authors and reviewers?

Policies work better with help attached.

• Publish a template code availability statement and a short author checklist.
• Link to training such as The Carpentries lessons for authors who have never published code.
• Tell reviewers in the invitation which languages and tools a submission uses, so they can decline or flag gaps early.
• Offer reviewers a short code checklist and permission to state limits on what they checked.
• Consider a dedicated reproducibility editor or a partnership with a verification service for high impact or high risk papers.
• Point authors of reusable tools to specialist venues such as the Journal of Open Source Software or rOpenSci review, where software gets deeper scrutiny.

How do you know a policy is working?

Measure it. Sample published papers each year and check: does the code availability statement exist, does the link resolve, is there a license, is the archived version identifiable, does the code run? A policy on paper and code that is actually available are not the same thing, and only checking tells you the difference. Spot checks close that gap and show where guidance needs to improve.

Where should a journal start?

If a journal has no code policy, the first move is easy: require a code availability statement in every paper. It costs authors a paragraph, it costs editors a field in the submission system and it makes the absence of code visible. Then move to deposit. Then, where resources allow, toward review.

The goal is not to punish researchers for imperfect code. It is to treat code as what it already is: part of the scientific record.