变量命名像密码一样难懂
刚学编程时，很多人图省事，把变量名起得跟谜语一样。比如用 a、b、temp 这种名字，过两天自己回来看代码，都得愣住：这 a 到底是用户年龄还是计数器？
写代码不是给自己留日记，而是给别人看的说明书。起个 userAge 或者 loginCount，谁看了都明白。别嫌麻烦，省下的那几秒钟，可能换来半小时的排查时间。
复制粘贴成瘾，不理解就用
网上搜到一段能跑的代码，二话不说直接复制进项目，改都不改。这种操作就像抄作业——作业交上去了，考试照样不会做。
有次看到一个新手在循环里反复请求数据库，每轮都查一次配置信息，结果页面加载慢得像蜗牛爬。问他为啥不提出来，他说“网上这么写的”。其实那段代码场景不同，照搬只会拖垮性能。
忽略错误提示，靠猜解决问题
程序报错，红字一大片，第一反应不是读提示，而是删代码、重启编辑器、甚至重装软件。这就像发烧不去看体温计，先换床睡。
编译器和解释器给出的错误信息，往往直接指出了问题位置和类型。比如 Python 报 IndentationError: unexpected indent，那就是缩进不对，盯着空格和 Tab 看就行，别瞎折腾其他地方。
代码乱写一通，从不测试小模块
一口气写完几百行，然后点运行，发现一堆错，根本不知道从哪开始修。这就像盖楼不打地基，最后一推全塌。
应该写一小段测一段。比如做个计算器，先把加法函数单独跑通，再写减法。用几个简单输入验证输出对不对。这样出问题范围小，好定位。
死磕一个问题超过两小时
卡在一个 bug 上，茶饭不思，越看越气。这种情况太常见了。其实人的大脑连续高强度运转，效率会急剧下降。
有个学员调试一个列表遍历的问题，纠结“为什么值没更新”，花了三小时。后来我让他停下，散步十分钟回来再看——原来是把 for 循环写成了
for i in range(len(items)):
items = [] # 这里清空了原列表以为学会语法就等于会编程
背熟 if、for、class 怎么写，不代表就能做出实用程序。就像知道砖头水泥怎么用，不等于会盖房。
真正的编程是解决问题的能力。比如要做个记账本，得想清楚数据存哪、怎么分类、界面如何交互。这些比语法重要得多。光会写代码，不会拆解需求，最后做出来的东西没人愿意用。
不写注释，也不留文档
“我现在记得清楚，不用写注释。”这话我听过太多次。可一个月后项目要修改，连自己当初为啥用这个算法都想不起来。
哪怕只写一行说明也好。比如：
# 防止负数金额导致统计异常
if amount < 0:
amount = 0