周爱民老师的大道至简翻开来像跟着一位带过无数新生的学长，一点点复盘我这学期编程作业里的那些磕磕绊绊。那些曾让我对着屏幕叹气的小错误、改到凌晨的bug，突然在书里找到了根由。作为刚啃完C语言和C++的大一学生，书里的话不像课本里的理论那样生硬，倒像是在说我过去半年的真实经历——原来编程里的那些坑，早有人把道理掰碎了讲透了。
这学期的编程作业，说起来都是些想当然酿成的麻烦。就说那次C语言写成绩统计程序吧，题目要求计算班里30个学生的平均分，还要找出最高分。我拿到题扫了一眼，觉得“这有啥难的”，直接打开编译器就敲代码。定义数组时随手写了intscore[30]，然后用for循环从1到30输入成绩，算完平均分才发现，数组下标明明是从0开始的，最后一个学生的成绩压根没存进去，平均分少算了一大截。改完这个错，又发现找最高分的时候，把初始值设成了0，结果班里要是全是不及格的分数，程序就会把0当成最高分输出。那天晚上改到一点多，屏幕上的数字看得我眼睛发花，最后总算跑通了，可代码里变量名不是s就是i，注释只潦草地写了句算分用。
后来同学指着我的代码笑：“你这变量名跟密码似的，过一周自己还认得吗？”还有次C++作业写一个简单的日期计算器，要求输入年月日，输出第二天的日期。我光顾着记“类里要写构造函数”，把“年、月、日”封装成private成员，却忘了考虑“2月有28天还是29天”“大月小月的天数不同”这些细节。结果程序输入“2024-2-28”，输出的是“2024-2-29”，可再输入“2024-2-29”，居然输出了“2024-2-30”——显然没处理月份进位的逻辑。那天对着屏幕里的“2月30日”发呆，突然想起书里说的“程序=算法+结构”，我这不就是只顾着“结构”（类的封装），忘了最核心的“算法”（日期进位的逻辑）吗？就像书里说的，“一接到任务就开始Coding的程序员，通常是加班最多的”，我可不就是这样？读了书才慢慢明白，这些问题远不止“粗心”那么简单。书里说“懒人造就方法”，可我总像个勤快的“愚公”，埋头敲代码却从不总结规律。比如算平均分那次，明明可以先在草稿纸上画个流程图：“1.定义数组时注意下标从0开始；2.输入前先提示‘请输入第n个学生成绩’；3.初始化最高分要用第一个学生的成绩而非0”，可我偏要“边想边写”，结果反复掉进同一个坑里。还有“语言只是工具”这句话，我以前总纠结“C++的类是不是比C的结构体高级”，写日期计算器时，为了用类而用类，反而把最该理清楚的“每月天数表”忘在了脑后——就像书里说的，“成天讨论这门语言好还是那门坏，是可悲的”，我连工具该怎么用都没搞懂，倒先比起了工具的“高低”。最可惜的是，每次改完bug都像完成了任务，从没想过“为什么会错”，下次遇到类似的题，还是会在同一个地方摔跤。
书里说“知其然而不知其所以然”，说的不就是我吗？要是早看到这本书，或许我的作业能少些狼狈。这阵子我试着按书里的思路改了改习惯：拿到题目先别急着开编译器，花十分钟在草稿纸上写“步骤清单”。比如写冒泡排序时，我会先写下“1.外层循环控制排序轮数（从0到n-2）；2.内层循环比较相邻元素（j从0到n-1-i）；3.每轮结束后，最大的数会沉到末尾”，把“顺序、分支、循环”这些逻辑理得明明白白，再画个简单的流程图，标清楚哪里可能出问题。写代码时，逼着自己给变量起“能说清意思”的名字，比如“maxScore”“currentDay”，在关键步骤旁写注释：“//这里i要减1，因为数组下标从0开始”“//2月的天数要判断是否为闰年”，就像书里说的“为后来的自己留沟通渠道”。每周还会把作业里的bug记在笔记本上，标上“错误原因”和“解决办法”，比如“数组越界：循环结束条件应该是i<n而非i<=n”“字符串输入：用%s而非%d”，慢慢攒成自己的“避坑笔记”。原来编程的“大道”真的藏在简单里：先想清楚再动手，让代码自己说话，错了就记下来。以前总觉得编程是“跟电脑较劲”，现在才明白，它更像跟自己较劲——较劲能不能把逻辑理得更顺，能不能让一周后的自己、甚至同桌看懂你的代码。这本书让我知道该往哪走，才能避开那些藏在代码里的坑。往后再写代码，大概不会再像以前那样了。
