本人郑重声明：所呈交的《复古C语言游戏代码修复与解析—66 FriendlyPair》是本人独立进行研究工作所取得的成果。除文中已经注明引用的内容外，本成果不含任何其他个人或集体已经发表或撰写过的作品成果，本人完全意识到本声明的法律结果由本人承担。

摘要

本次课程任务围绕复古C语言游戏代码展开修复与解析工作，选取编号66的代码为研究对象，通过Dev-C++、VSCode等编译工具完成代码的编译、调试与错误修正，解决了古老C语言语法与现行标准不兼容的问题，同时完成代码功能解析、重命名及基于VSCode和Git的项目管理与版本控制。通过本次任务，深入理解了C语言语法标准的演变，掌握了代码调试和项目管理的基本方法，提升了实际编程与问题解决能力。

1. 选题与准备

1.1 选题

本次选取GameCode155文件夹中编号为66的代码文件，代码量适中且包含典型的复古C语言语法特征，适合作为入门级的代码修复与解析案例，能较好地体现从编译错误排查到功能理解的完整流程，符合课程任务对复古代码修复的练习要求。

1.2 环境准备

• 操作系统：Windows 11

• 编译器：Dev-C++ 5.11、VSCode 1.85.1 + gcc 8.1.0

• 辅助工具：Chrome浏览器（搜索引擎）、ChatGPT（AI工具）、Visio 2019（流程图绘制）、Git 2.43.0（版本控制）豆包 deepseek

2. 编译调试过程

2.1 初始编译与错误分析                                                                                                                   

   

原始代码存在语法标准不兼容、缺少头文件、非标准函数调用三类核心错误，这些问题会直接导致代码在现代编译器中编译失败或运行异常，具体错误点如下：

1. 主函数声明不符合C语言标准

错误代码：void main()

问题原因：C99/C11等现行标准中，主函数的标准声明为int main()，且需在函数末尾通过return 0;返回整型值；void main()是早期非标准的写法，现代编译器（如gcc、VS）会报“main函数返回类型错误”的编译错误。

2. 缺少必要的头文件

问题1：使用clrscr()（清屏函数）、getch()（按键等待函数）时，未包含<conio.h>头文件，编译器会提示“未定义标识符clrscr/getch”。

问题2：若用system("cls")替代clrscr()实现清屏，还需包含<stdlib.h>头文件，原始代码同样缺失。

3. 调用非标准/过时函数

错误代码：clrscr();

问题原因：clrscr()是DOS时代Borland C/C++的专属清屏函数，属于非标准库函数，现代Windows/Linux编译器（如gcc、MSVC）均不支持该函数，会直接报编译错误。

4. 潜在的输入输出兼容问题（非编译错误，影响运行体验）

错误代码：getch();

问题原因：getch()同样来自<conio.h>，虽部分编译器（如Dev-C++）仍兼容，但在纯gcc环境下可能无法正常运行；且原始代码未处理scanf()后的缓冲区残留字符，可能导致getch()触发异常。

2.2 错误修正

亲和数对代码极简修正过程

针对原始代码的4个核心问题，按“问题-修正操作”的形式极简梳理修正步骤，直接对应解决编译/运行错误：

1. 主函数声明错误

问题：void main()不符合C标准

修正：改为int main()，并在函数末尾加return 0;

2. 缺失头文件

问题：使用clrscr()/getch()缺<conio.h>，用system()缺<stdlib.h>

修正：代码开头添加#include<conio.h>和#include<stdlib.h>

3. 非标准清屏函数

问题：clrscr()仅兼容老式编译器，现代编译器不支持

修正：替换为system("cls")（Windows）/system("clear")（Linux/Mac）

4. 输入缓冲区残留问题

问题：scanf()后换行符残留，可能导致getch()异常

修正：在scanf("%d",&n);后加while (getchar() != '\n');清空缓冲区

2.3 反复调试

将修正好的代码再次在dev-c++中编译 消除所有错误与警告 编译结果显示0错误 0警告 完成调试。

3. 代码理解与重命名

3.1 运行测试

本次测试基于Dev-C++ 5.11（集成gcc 8.1.0编译器）与Windows 11操作系统，选取三组不同查找范围作为测试用例，验证代码功能完整性与运行稳定性。测试结果如下：当输入查找范围n=300时，程序成功输出经典最小亲和数对“220..284”，符合亲和数定义；输入n=10000时，新增输出“1184..1210”，验证了范围扩展后的查找有效性；输入n=20000时，进一步输出“2620..2924”，无重复输出或结果遗漏现象。运行过程中，小范围查找（n≤10000）响应迅速，大范围查找（n=100000）仅需短暂等待，程序无闪退、乱码等异常，输入输出交互流畅，按任意键后可正常退出，完全满足设计预期。

3.2 代码解析

输入输出模块：通过printf函数输出亲和数定义说明与操作引导，界面友好且信息明确；采用scanf函数读取用户输入的查找范围n，结合%4d格式化输出亲和数对，确保结果显示整齐规范，提升可读性。因子和计算模块：作为代码核心，通过两层嵌套循环分别计算数字a与b的真因子和。其中，真因子定义为“除自身外能整除该数的正整数”，循环终止条件设为i≤a/2（或i≤b/2），因大于数字一半的数不可能成为其因子，该设计有效简化计算流程、提升运行效率。例如，计算a=220的真因子和时，循环遍历i=1至110，累加所有能整除220的整数，得到b=284；再通过相同逻辑计算b=284的真因子和，得到m=220，完成核心计算环节。亲和数判断模块：通过双重条件判断                     “m==a&&a<b”筛选有效亲和数对。其中“m==a”确保满足“a的真因子和为b，b的真因子和为a”的亲和数定义，“a<b”则避免同一数对重复输出（如220与284仅在a=220时打印，a=284时跳过），保   证输出结果的唯一性与简洁性。         

3.3 重命名

根据代码的功能，将原文件66.重新命名为66 FriendlyPair，清晰体现文件的核心功能。

4. 使用VSCode管理项目

4.1 VSCode环境配置

1. 下载并安装VSCode软件，在扩展商店中安装“C/C++”插件（Microsoft官方版本）。

2. 配置系统环境变量，将gcc编译器的路径（如MinGW\bin）添加至Path中。

3. 在VSCode中打开文件夹，通过Ctrl+Shift+P打开命令面板，执行C/C++: Edit Configurations (UI)，配置编译器路径为gcc.exe。

4.2 在VSCode中编译运行

5. 代码版本管理

5.1 Gitee仓库创建

打开Gitee官网，注册账号后创建名为“Retro-C-Game-Code”的公共仓库，仓库描述为“复古C语言游戏代码修复与解析”。

5.2 VSCode中集成Git

1. 在VSCode中安装“Git History”“GitLens”插件，便于Git操作与版本查看。

2. 在项目文件夹中右键打开终端，执行git init初始化本地仓库，git add .将代码文件加入暂存区，git commit -m "初始化猜数字游戏代码"完成本地提交。

1. 关联远程Gitee仓库：https://gitee.com/qmz777/qmz777.git

6. 总结

本次课程任务围绕复古C语言代码展开修复与解析，过程中遇到了语法标准不兼容、废弃函数使用、非标准库函数调用等问题，通过查阅资料、替换标准函数、调整语法格式等方式完成了代码修复，最终实现程序的正常编译与运行。

通过本次任务，我不仅深入理解了C语言语法标准的演变过程，掌握了代码调试、错误排查的基本方法，还学会了使用VSCode进行项目管理以及Git与Gitee的版本控制操作，认识到规范编程与版本管理在实际开发中的重要性。同时，在解析代码功能的过程中，也加深了对C语言循环、分支结构及标准库函数的理解，为后续C语言编程学习奠定了更坚实的基础。

附录

1. 代码地址：Gitee仓库链接https://gitee.com/qmz777/qmz777/blob/master/1.c
2. 相关参考资料：

     C语言标准文档

     Dev-C++官方使用手册

     VSCode C/C++插件配置指南

     Gitee Git版本控制入门指南（Gitee帮助中心）