大家如何看待代码中的拼写错误？

[mikewang]

举几个例子我看见过的：

红帽是 redhad ，乌班图是 ubutu ，
加密是 encript ，解密是 discrypt ，
前台是 forground ，后台进程是 damon 。

最初是项目里编译出 lib/redhad/lib*.so，这个 redhad 让我震惊了一整天。

---

刚接触代码时，我是想去改掉的。但是了解到这个目录 N 年前就是这样了，而且也不清楚到底有多少依赖，便作罢。

后来我也佛系了，毕竟不关我事，能跑就行。

直到我某天写代码，要用到一个大写的常量 某 DEFALUT ，怎么看怎么怪，定睛一瞧还是拼错的。一搜发现有三十多处。

---

如果是你，该怎么办？

1. 全改掉
2. 捏着鼻子继续用

---

...我最终还是选择了 2 ，因为前者会让 git blame 全变成了我，而我并不想背这个锅...

[nzbin]

这个是代码习惯问题，我一般写变量都会刻意多看几眼，偶尔写错也可以理解，数量不多就改过来，历史代码能不改就不改
吐槽：同事代码 newOption 能写成 nowOption ，我愣是研究了大半天才明白是啥，可以想象这种代码得多难维护

[yanyao233]

ide 不是会有提示吗，很多缩写识别不了也提示，都给我整麻了

[boris1993Jr]

@yanyao233 #22 可以添加到个人词典吧？

[chendy]

@yanyao233 alt + enter -> save 'typo' to dictionary

[adoal]

以前有个段子，股市行情好的时候坐台小姐到证券公司当交易员，行情不好的时候交易员坐台当小姐。

红利行业就是这样，对人的需求大于供给，各种阿狗阿猫都会冲进来。

（程序）又不是不能跑、（人）又不是不能跑。

你能做的就是尽量往高水平的团队去。

[raptor]

我碰到 reason 拼成 resaon 的，我让他改了，别的团队的同事，我直接在公司群里说这个单词拼写错了，他下个版本就改了。反正都是公司内部对接的东西，大家一起改一下就是了。

[wangkun025]

能改就改。
不能改就注释。
不能注释，你妹夫的，跟你拼了。

[churchill]

说实话大部分拼写错误放在上下文中都不影响阅读
怕乱起名的，怕 define FALSE true 的

[lykhero]

这个就是不认真 不要洗什么学历什么的 不认真就是不认真 完全可以查了之后自己背一下的
又不是考托福雅思 就这么几个单词

[cctv1005s927]

安全的地方尽量改掉，并在 review 的时候，引导身边的人尽量注意拼写的问题。
正确的事情应该坚持，你有大大方方做的理由，不要犹豫。

[lambdaq]

前鼻音 后鼻音 平舌翘舌搞混的多得很。

[shuimugan]

外部的不管，自己团队的坚持开拼写检查，碰到写错的坚决改，碰到离谱的还要拿出来鞭尸。妈的以前有个功能在开发文档里叫去重，有个同事查了下翻译然后字段写了个 go_heavy ，震惊我一整年，被我长期拿来做反面例子，教育他们一定要看 IDE 的告警，提交前要保证所有告警消失。

[celeron533]

说明之前的团队不怎么样
- 英文水平不佳
- 不认真
- 没有 code review

[twofox]

对于我这种英语水平一般的人，copilot 和 gpt 真的帮了大忙。。很多变量不知道怎么命名合适，就靠这两个

对于这种历史的拼写错误，如果是我写的，我就会改。不是我写的，凑合用

[FlytoSirius]

现在来看, 改动之前库里这些错别单词确实不现实,

但新的代码, 至少可以通过 "静态代码检查" 类的工具大幅减少这类问题的出现, 降低 human review 的压力, 毕竟人去 review 代码主要还是集中在 代码逻辑 上吧.

[FlytoSirius]

我个人 不太觉着靠引导别人能让他人解决英文拼写问题, 直接把 "拼写检查" 放在 CI 的 pipeline 里, 每次提交代码都必须 pipeline 运行通过, 你看他们都自己改不改拼写...

[Felldeadbird]

影响不大，只是作用域内，可以改。
一旦超出了作用域，你要慎重修改了。

[iqoo]

#define mian main
#define ture true

[Sprdance]

老代码基本没办法再更改了，不过可以拿出来当反面教材学习学习
新代码合入检视的时候，在 IDEA 里看看哪里有黄色波浪线，大概率就是拼写错了

[julyclyde]

你是不是腾讯的？