赶在截止日前一晚，对着文档发呆，才认真琢磨计算机实验报告怎么写，之前总以为就是把代码粘贴上去交差，连着两次提交都被打回来，批注写着缺少实验分析，数据描述太单薄，老师说看不出我到底有没有动手跑过程序。
最开始的版本，结构很简单，开头写实验目的，然后贴上完整代码，最后一句实验成功就收尾。代码是在机房里调通了，截图也截好了，可交上去之后，才明白这里缺了很多东西。运行的时候出现过报错，数组下标越界，反复改了两三处地方才正常输出，这些调整的过程，全都没有写进去。当时下意识觉得，报错是自己操作不对，不用写进报告里，只留下顺利运行的结果就行。
后来翻看同班同学交的一份，他没有把大段代码直接堆在页面里，只保留核心片段，剩下的位置用来写每一步操作对应的现象。输入什么样的测试用例，控制台返回了什么内容，预期想要得到的输出是什么，实际拿到的结果有没有偏差，一条条顺着实验的顺序记下来。他还把调试时看到的提示信息简短写了几句，没有长篇大论解释语法，就记录下自己修改的位置，以及改动之后发生的变化。
实验原理部分不用抄课本上整段定义。之前我习惯直接复制课件文字，篇幅拉得很长，和本次实验用到的知识点对不上，读起来很空泛。现在一般只挑和这次程序、这个实验任务直接相关的内容，简单写清楚原理支撑到哪一步，够用就停下，不用拓展别的分支知识点。
实验步骤这块，别写成代码注释。
要站在操作的角度去写，打开开发环境，新建项目文件，引入需要的头文件或者模块，编写代码，保存文件，编译，运行，更换多组测试数据重复验证。每一步不是复述代码逻辑，而是记录人在电脑上完成的动作。测试用例尽量准备两组以上，一组常规情况，一组边界情况，边界值跑出来的结果往往更容易体现思考，也是之前我常常漏掉的地方。
结果分析是整张报告里占比最重的一块，也是我最容易偷懒的地方。拿到运行截图之后，不能只说结果正确。要对照测试数据，说一说输出为什么符合预期，如果有一组数据的结果和预想不一样，就写清楚排查的思路，是条件判断写错，还是循环终止条件设置的问题，最后怎么调整才对齐。哪怕最后没能完全调通，也可以如实写明卡在哪个位置，尝试过哪些调整，当前程序表现出来的现象是什么。这只是我的个人感受，不是标准答案，有的任课老师偏好完整成功的实验记录，也有的更愿意看到真实完整的调试思考。
最后的实验小结，不用拔高，不用讲学到了多么深刻的道理。就写这次实操里暴露出来的问题，比如对某个语法的理解不够扎实，测试的时候只想着顺利跑通，忽略异常输入，下次做同类实验的时候，可以提前准备多几组测试样例。小结控制一小段就够，写多了容易变得空洞。
代码的摆放也有讲究，全部粘贴进去会挤占阅读空间。可以只放核心代码段，无关的冗余代码省去，代码旁边配上简短标注。截图要把完整的运行界面截下来，命令行输出、程序返回内容都清晰可见，不要只截取一小段结果数字，别人看不出这组数据是怎么跑出来的。文件命名也记得按课程要求统一，避免上交的时候归类混乱。
有一回做循环结构实验，测试负数输入的时候程序没有做出对应的分支响应，当时急着交作业，直接删掉这条测试数据，换了一组能正常通过的数字。那份报告分数很低，老师标注，刻意避开异常场景，报告失去记录实验的意义。之后再写，不管结果好坏，都保留全部测试记录，差异和疑问都原样写下来，不再刻意美化整个实验流程。
没有固定模板必须死死遵守，每个任课老师的要求会有差别，有的会单独指定固定章节顺序，有的允许自由排布内容，上交前最好扫一眼课程群里发过的要求，优先贴合老师给出的框架。我这套写法，只是一次次被退回之后慢慢调整出来的版本，只适合当作一个参考样本，直接照搬很容易和老师的要求错开。
写完之后，从头顺一遍。读的时候想象自己是没做过这个实验的人，能不能顺着文字看懂整个实验做了什么，程序怎么运行，中间遇到了什么状况，最后得到哪些结论。读起来断断续续、信息跳得厉害的地方，就补上几句简短描述，不用额外堆砌文字。
机房下课铃响的时候，屏幕还停留在报告文档页面，光标悬在小结那一行，想想下次再写，先把测试数据和报错提示随手记在记事本里，不要等到深夜整理的时候，早就记不清当时调试的细节了。