论文附源码的行业标准与实践指南
主流期刊对源码提交的核心要求
计算机领域TOP会议（如NeurIPS、ICML）近年将代码可复现性纳入评审标准，CVPR2023数据显示87%的录用论文都附带了完整源码包。常见要求包括：
/src # 核心代码
/data # 示例数据
/results # 预训练模型
开源协议：推荐使用MIT或Apache 2.0等允许学术使用的协议
期刊名称
代码审查比例
接受格式
IEEE TPAMI
92%
GitHub/Zenodo
ACM TOG
85%
机构存储库
代码可复现性的技术实现
南京大学2023年研究发现，具备以下特征的论文代码被引用量高出23-46%：
版本控制：强烈 使用Git管理，提交时注明commit hash
环境封装：Docker镜像或conda环境配置文件（environment.yml）能解决80%的依赖问题
单元测试：包含测试用例的代码库通过审核时间平均缩短2-3天
实际操作中要注意：
避免提交IDE配置文件（如.idea/）
二进制文件 通过Git LFS管理
敏感数据需进行脱敏处理
学术平台与开源社区的协同
arXiv现在支持直接关联GitHub仓库，但要注意：
主分支必须包含完整可运行代码
补充材料中应注明代码仓库的访问方式
持续集成（CI）配置能显著提升可信度
ACM最新模板已内置代码附录章节，推荐结构：
latex
section{Code Availability}
begin{itemize}
item Repository: url{https://github.com/xxx}
item DOI: 10.5281/zenodo.xxxx
end{itemize}
### 常见错误与优化方案
审稿人最反感的三大代码问题：
缺少版本说明（32%的拒稿案例涉及）
路径硬编码（改用相对路径可避免）
依赖项版本冲突（ 使用requirements.txt精确指定）
优化技巧包括：
使用Jupyter Notebook时导出为.py文件
添加命令行参数解析（argparse）
在README中注明最低硬件要求 当论文附带的代码或模型文件体积过大，超出期刊规定的附件大小限制时，确实会让很多研究者头疼。最稳妥的做法是使用Git LFS（大文件存储）来管理这些”重量级”文件，它能将大文件单独存储在云端，只在本地保留指针，既解决了存储问题又不会影响版本控制。比如一个10-20GB的预训练模型，用Git LFS处理后，提交到GitHub仓库就完全不是问题。
另一个专业方案是把大文件上传到Zenodo、Figshare这类学术存储平台，它们不仅提供稳定的长期存储，还会为每个上传的文件分配专属DOI。这样在论文里只需引用这个DOI，审稿人就能直接获取文件。如果实在要用网盘链接，记得选择那些不会轻易失效的服务，比如Google Drive或机构自建的云存储，并在README里明确标注”此链接至少保持5-10年有效”，同时 在补充材料里也备份一份下载说明。
论文必须附带源代码才能发表吗？
并非所有期刊都强制要求附源码，但计算机领域TOP会议（如CVPR、NeurIPS）近年录用论文中87-92%都包含完整代码。 查看目标期刊的，若研究涉及算法实现或实验复现，附源码能显著提升通过率。
代码文件大小超过期刊限制怎么办？
遇到大文件（如预训练模型）时，可采用三种方案：1）使用Git LFS管理大文件 2）上传至Zenodo等学术存储库并标注DOI 3）在README中提供百度云/Google Drive下载链接（需确保长期有效）。
使用GitHub仓库提交时要注意什么？
必须满足三个条件：1）仓库设为public 2）主分支代码与论文描述完全一致 3）包含完整的版本标签（如v1.0对应投稿版本）。 额外在论文补充材料中注明commit hash和仓库快照DOI。
如何选择适合的开源协议？
学术用途推荐MIT（最宽松）或Apache 2.0（含专利条款），若涉及医疗等敏感领域可选GPL-3.0（要求衍生作品开源）。注意CC-BY-NC等协议可能阻碍工业界应用。
审稿人要求补充代码文档该怎么办？
立即更新仓库并补充：1）函数级docstring 2）Jupyter Notebook示例 3）API说明文档。可通过GitHub Pages自动生成文档网页，在rebuttal阶段提交更新链接。
