命名混乱，自己都看不懂的代码
刚入行那会儿，我也喜欢用 a、b、c 当变量名，觉得写得快。直到有天要改半年前写的登录校验模块，翻来覆去找不到哪个 b 是用户输入的密码——那一刻真想抽自己。像 user_input、temp_flag 这种模糊命名，在团队协作中更是一场灾难。建议直接用语义明确的名字，比如 is_password_valid 比 flag 强十倍。
缩进和空格，看着不起眼却影响深远
有人爱用两个空格，有人坚持四个，还有人用 Tab。项目一混合，代码格式立马变花脸。更麻烦的是，某些语言（比如 Python）对缩进敏感，一个错位就能让服务直接报错崩溃。团队最好统一 .editorconfig 规则，新成员一拉代码就自动对齐。
注释写得像谜语
“修复逻辑”、“临时处理”——这种注释等于没写。我见过最离谱的一行注释写着“这里不能动”，结果删了之后支付功能全挂。好的注释应该说明“为什么这么做”，而不是重复代码在“做什么”。比如：
// 避免浮点数精度问题，金额统一按分存储
int amountInCents = (int)(amount * 100);硬编码密钥，等于把家门钥匙贴外墙上
开发测试时图省事，数据库密码、API 密钥直接写在代码里。代码一旦上传到公共仓库，黑客分分钟就能连上你的生产环境。之前有个同事把阿里云 AK 写进 JS 文件，不到两小时就被扫走跑了个挖矿程序。正确做法是通过环境变量或配置中心管理敏感信息。
异常处理敷衍了事
try-catch 一裹，print 接个 error 就完事？这种写法最大的问题是：出了问题根本没法追踪。日志没上下文，错误不报警，线上服务挂了都不知道从哪查。至少要把关键参数、堆栈信息记进日志，必要时触发告警。
忘了输入校验，给攻击者递刀子
用户注册时不限制用户名长度，结果有人提交了个 5MB 的字符串，直接把数据库连接池拖垮。还有的接口没过滤特殊字符，SQL 注入漏洞就这么敞开着。别相信任何前端验证，后端必须对所有输入做清洗和长度限制，哪怕是内部调用。
代码重复，改一处漏三处
复制粘贴一时爽，修改时火葬场。三个地方都有同一段权限判断逻辑，改需求时只改了两处，第三处就成了越权入口。该封装成函数的别手懒，共用逻辑放工具类，改一次全项目生效，还能减少出错概率。