代码已放Git仓库，投The BMJ还要作为补充文件上传吗？

分析代码已放在公开仓库，投《The BMJ》的作者便打算在方法段写“代码见仓库”，不再上传文件。对 2024 年 5 月 1 日或之后提交的研究论文，《The BMJ》说明要求提交用于数据分析和生成结果的代码，并希望代码作为补充文件提供，理想情况下也存入持续可访问的代码库。仓库链接便于定位材料，但并不自动代替期刊系统里的文件和版本记录。

先界定要交哪些代码

把论文每一张主要表和图回指到清洗、建模、汇总和作图步骤。如果只交最后一个制图脚本，而缺失把原始字段转为分析变量的代码，别人无法理解结果如何得到。反过来，与研究无关的临时文件、个人密钥和受限制的数据不应混入代码包。整理一个清单，标出每个文件的输入、输出、运行顺序和与论文结果的对应关系。

《The BMJ》的政策强调分析代码要机器可读、适当注释，并在给定合适数据时可以运行。若使用图形界面软件，应尽可能导出底层处理和分析语法；一张操作截图不能代替可执行的步骤。开源仓库可用于提供版本控制，但初投稿要固定对应的提交版本，避免几周后仓库主分支更新，编辑看到的脚本已经不同于论文所用版本。

补充文件与仓库各负其责

补充文件可保存该次投稿的固定副本，仓库可保存完整开发历史和后续维护。两处都要标同一版本或提交编号，并写清软件版本、依赖包、运行入口和预期结果。若代码运行需取得受控数据，注明数据访问限制与可用的演示输入，切勿上传含参与者信息的样本文件。若论文用的是商业软件，也要说明版本和可导出的可复核语法，不能只给软件名称。

例如作者把结果表的脚本提交为一个压缩包，其中还调用了本地路径的自定义函数。另一台电脑下载后立即报错；这时应补齐依赖文件和相对路径，并在说明里写清执行顺序。若确有第三方许可证限制，先厘清哪些代码可以提交，哪些部分需要替代说明，再与编辑沟通。不能以“仓库里都能找到”掩盖实际上无法运行的状态。

提交前做一次复跑

让未参与写代码的合作者按说明在干净环境中运行，以脱敏或模拟数据核验流程，记录报错与修正。再对照主稿、补充文件和仓库版本，确认系数、图号和样本筛选逻辑一致。若期刊系统把补充文件另行命名，上传后再下载一次，确认文件完整、没有损坏，说明文档中的文件名仍对应。准备代码的目标，是让编辑能追溯结果，而不只是多交一个文件。

参考信息：《The BMJ》“Data and code sharing for research papers in The BMJ”中代码提交、注释、软件与版本要求。