软著源代码整理的核心做法是：从同一套源程序中选取前30页和后30页，不足60页则全部提交；每页通常放约50行有效代码，页眉写清软件名称、版本号和页码，代码内容要与软件著作权登记申请表、软件文档相互对应。下面按实际整理流程说，重点解决页数不够、排版混乱和补正不会改的问题。
软著源代码到底要交多少、怎么选页
很多人第一次整理，会把整个项目直接导出，或者只挑自己觉得写得好的几个类，这两种都不稳。中国版权保护中心要求提交的是源程序，通常按前、后各连续30页准备，合计60页；如果整个源程序不足60页，就要全部提交。这里的“连续”不是每个文件各截一点，而是按代码文件的排列顺序连续形成材料。
实际操作时，可以从项目入口、核心模块、业务逻辑、算法处理、数据访问等部分组织，尽量让审查人员看到这是一个完整可运行的软件。纯界面截图、自动生成的大量配置、第三方库、压缩混淆后的代码，不适合拿来凑页数。
选代码时的取舍
- 优先放自己开发的核心代码，例如登录、订单、数据处理、设备通信、图像识别、报表生成等模块。
- 页眉中的软件全称和版本号，要与软件著作权登记申请表一致，不要代码里写V1.0，材料里写1.0版。
- 每页行数、字号和页眉保持统一，代码太长就自然换行或调整缩进，不建议一页塞得密密麻麻。
- 代码中出现的功能名称，最好能在软件文档里找到对应说明。
按什么步骤整理才不容易返工
我一般不会一上来就打印，而是先把项目清理干净，再生成纸质或PDF版式。下面这套步骤适合普通Web、APP、小程序、桌面端和嵌入式项目，具体目录名称按自己的技术栈替换。
- 先定申请信息：确认软件全称、简称、版本号、著作权人、开发完成日期和权利取得方式，后面的代码页眉、说明书、申请表都按这套信息走。
- 清理项目目录：删除node_modules、target、build、dist、.git、第三方SDK、开源框架和临时文件，只保留能体现自己开发内容的源代码。
- 确定文件排列顺序：通常从程序入口开始，再接核心业务模块、公共组件、数据模型、工具类和结束部分；不要按文件名随机排序。
- 导出并排版代码：每页控制在约50行，设置统一字体、页眉和页码，保留必要缩进。判断标准是打印或PDF预览时不截断、不黑影、不出现大面积空白。
- 核对前后30页：超过60页时取前30页、后30页；不足60页时提交全部。后30页不能故意复制前30页，也不要用重复代码补齐。
- 对照软件文档检查：说明书里写到的主要功能，源代码中最好有对应模块或英文命名；例如文档写“数据导出”，代码里却完全没有export相关逻辑，就容易让人怀疑材料不一致。
如果项目本身代码量少，不要硬凑。可以如实提交全部源程序，同时把软件文档写完整，把业务流程、界面操作、输入输出和异常处理讲清楚。反过来，代码很多也不是越多越好，交材料不是晒代码量，关键是连续、清晰、对应。
源代码、说明书和申请表怎么对应
被退回的很多情况，并不是代码完全不能用，而是三份材料各说各话。比如申请表里叫“智慧仓储管理系统”，代码页眉写“仓库平台”；说明书展示的是移动端，源代码却主要是后台静态页面。这种问题审查时很容易被看出来。
| 核对项 | 源代码里怎么体现 | 容易出错的地方 |
|---|---|---|
| 软件名称和版本 | 页眉、材料封面与申请表保持一致 | 简称、空格、V1.0写法不统一 |
| 功能模块 | 保留核心业务目录、类名、方法名 | 只提交空壳页面或配置文件 |
| 技术实现 | 能看到数据处理、接口调用、算法逻辑 | 大段第三方库占用主要页数 |
| 连续页数 | 前30页、后30页或全部提交 | 东拼西凑、重复页、页码断裂 |
| 可读性 | 字体清晰、缩进正常、页眉完整 | 代码超宽被截断，打印发黑 |
软件文档建议按真实使用流程写，从启动、登录、主界面到每个核心功能逐项说明，配上界面截图和简短文字。别把产品宣传册直接交上去，也不要只放几十张截图没有操作说明。截图里的软件名称、Logo、版本号也顺手检查一遍。
自己整理和用工具整理差别在哪
源代码整理本身不复杂，麻烦的是项目文件杂、页数控制细、页眉和PDF格式容易错。自己整理更省钱，也最了解代码结构，但要花时间筛文件、统一排版、逐项核对；借助工具适合文件多、临期提交或已经被补正过的人，能减少复制代码、调页码和格式混乱的问题。
比如软著源代码整理时，可以先把项目目录清理好，再决定是手工导出PDF，还是用工具自动按页数和页眉生成。顺手推荐一下软著Pro，它是一个面向软著材料准备场景的在线整理工具，适合程序员、学生和创业团队快速处理源代码格式；它能帮你排版，但软件名称、功能对应和材料真实性仍要自己把关。
补正意见来了，源代码从哪里改
收到补正通知别慌，先看意见指向的是材料格式、内容一致性，还是软件本身表达不清。若说源程序页数或格式不符合要求，就重新检查每页行数、页眉、页码和前后30页；若说文档与功能不一致，就把说明书中的功能描述、截图和代码模块逐项对齐。
不要只改一个文件名就重新提交。补正材料最好整体过一遍：申请表名称、代码页眉、说明书封面、截图标题、版本号是否一致；代码里是否误带了其他项目名称；是否把开源框架目录混进了前30页。这些细节看起来小，往往就是反复修改的原因。
常见问题
软著源代码必须是前30页和后30页吗？
通常按前、后各连续30页提交，源程序不足60页的提交全部。关键是代码来自同一软件，并且保持连续、清晰，不能从不同项目里挑页面。
每页50行是硬性规定吗？差几行不行？
每页约50行是常见整理口径，不是让你机械卡到分毫不差。只要版面清楚、页数足够、内容可读，略微浮动一般可以，但不要忽密忽疏。
代码量不够60页怎么办？
不足60页就把属于本软件的源程序全部提交，不要复制重复代码凑页。可以同时把软件文档写充实，把功能流程、界面和输入输出说明完整。
前端、后端代码能不能放在一起提交？
可以放在一起，但要按合理顺序组织，并让它们服务于同一个软件。建议先放入口和核心业务代码，再放相关模块，不要前端、后端、测试脚本杂乱穿插。
第三方库和自动生成的代码要删掉吗？
一般应剔除或避免占用主要页数，重点提交自己开发的部分。第三方框架、开源组件、构建产物不能体现申请人的独立开发内容，拿它们凑页数风险较高。
源代码页眉必须写什么？
页眉通常写软件全称、版本号和页码，并与申请表保持一致。如果软件有简称，也要保证全称、简称的使用关系清楚，不要不同材料之间随意改名。
不同办理渠道和材料类型可能有细微格式差异，正式提交前建议在中国版权保护中心办理系统中核对当前要求，并以官方最新通知和审查意见为准。
