如何找出源代码中的拼写错误是否是一个严重的问题？[关闭]

我发现每天在我们的代码库中看到的拼写错误非常令人不安，我将重现一个非常简短但具有代表性的示例：

ArgumnetCount
Timeount
Gor message from queue 

不幸的是，这绝不仅限于一个人。我们的团队中有很多非英语母语人士对此做出了贡献，但是我也可以指出一些最糟糕的拼写错误给我们出生，成长为美国人的软件架构师。

这些信息甚至可以在电子邮件，演示文稿，文档中找到，无论我们在软件开发公司中拥有任何书面信息。

我想知道如何确定是否是一个严重的问题？

_{我一直很担心遇到这些拼写错误，但是我自己的个人官方政策是，我们没有为正确地拼写事情付费，而是为完成事情而付费，因此在公司内部，我从未真正批评任何人。但是我已经和我的一些密友提出了这个问题，但从未永远解决。}

拼写错误可能意味着两件事之一：

• 制作它们的人不会精通英语，也不会花时间通过使用适当的工具（词典，拼写检查器等）进行补偿。
• 制作它们的人精通英语，但根本不关心拼写。

要么是一个相当糟糕的信号，因为这意味着所讨论的人在他们的优先级列表中没有很高的可读性，可维护性和优雅感。如果原因是缺乏英语水平，这也意味着该人缺乏两项基本技能-书面英语交流和对语言的一般感觉（如果您无法用英语清楚地表达自己的想法，则有可能做到）也不能用编程语言很好地表达它们）。

但是，为什么在其他所有条件都相同的情况下，拼写错误到底是不好的呢？毕竟，代码可以工作，并且只要标识符不违反语法规则，编译器就根本不关心如何命名标识符。原因是我们不仅为计算机编写代码，而且还为人类编写代码。如果不是这种情况，我们仍将使用汇编。源代码只编写一次，但是在其生命周期中却读取了数百次。拼写错误会使阅读和理解源代码变得更加困难-轻微的错误会使读者跌倒一秒钟的时间，其中许多会导致相当大的延迟；真正糟糕的错误会使源代码完全不可读。还有另一个问题，就是您编写的大多数代码将被其他代码引用，并且该代码多半是由其他人编写的。如果您拼写错误的标识符，则其他人将不仅要记住（或查询）名字，而且还要记住拼写的准确程度。这会花费时间并中断编程流程。而且由于大多数代码在维护中会被多次触摸，因此每个拼写错误都会导致大量中断。

考虑一下开发人员时间等于薪水等于费用，我认为这很容易做到。毕竟，中断流程并重新进入流程最多可能需要15分钟。这样，严重的拼写错误很容易在进一步的开发和维护中花费数百美元（但它们是间接成本，在估计和评估中不直接可见，因此经常被管理层忽略）。

我实际上怀疑“ Timeount”是否不是讲母语的人的问题。人们用他们的第一语言输入大量的错字。我不会将这些特定示例视为“吸引人”。

话虽如此，我理解这与这些特定示例无关。我原则上同意你的看法。我遇到了由此类问题引起的实际麻烦（“如果没有名为Attachments的列，请创建附件”）。

成为一名程序员是要对错别字，逗号，分号和点进行精确和谨慎的处理，这在大多数情况下都是与人类语言无关的。

第一次浪费时间搜索Timeout变量只是为了将其写为Timeount，您就会知道拼写很重要的另一个原因。

如果这个问题困扰您，大多数IDE现在允许在注释中进行拼写检查，以便阅读困难的人至少看起来像他们知道如何拼写。它肯定可以帮助我！因此，具有良好的拼写是一个琐碎的“修正”。

公共类名称和方法中的拼写错误根本不专业。他们花费时间和金钱。在使用Java之类的静态类型语言时，它们很痛苦，IDE可以在其中生成类和方法名称的菜单。在动态类型语言中，它们是不能容忍的。

更糟的是数据库表名称和列名称中的拼写错误。

以我的经验，正确的拼写与编码人员的英语水平仅略有相关。我见过以英语为母语的人会产生具有基本随机拼写和单词中断功能的代码，也曾见过以英语为母语的非母语人士会小心地产生正确的拼写。但是正确的拼写与整体代码质量高度相关。有能力的程序员，不管他们的英语水平如何，都关心他们的工作质量，并谨慎命名。

在源代码，内部演示文稿和文档等中，不会改变含义或妨碍理解的小错字不是问题。如果发现它们很烦人，请自己修复源代码。

另外，尤其是在评论中，实质比形式更重要。在这里没有垃圾：

字符串s =“维基百科”；/ *将值“ Wikipedia”分配给变量s。* /

事实是，有些人天生比其他人更谨慎（无论是由于教育，态度还是智力或其他无关紧要的原因）。花费多少精力来解决这是一个商业价值问题：与花费很多精力来解决错别字相比，您能从纠正错别中获得更多的价值吗？如果是内部人员，答案通常是“否”。您的客户不会抱怨源代码注释中的拼写错误（除非您使用的是开源代码）。

故意错误键入和不适当的评论是不专业的，应避免，但重点应放在重要的事情上（即，如果您为企业工作，则可产生商业价值）。

当然，公开可见的内容必须经过仔细校对。

这里的问题不是滋味本身，而是缺乏评论的清晰度。不需要完美的英语，清晰的英语是必需的。通过Google运行某些操作以提取明显的错误很简单。

例如，乍一看不清楚是Gor message from queue指“从队列中获取消息”还是“从队列中获取GOR消息”。您需要阅读代码以理解注释的含义（从而击败注释的对象）。

您应该要求在公司中实施代码审查。然后，您可以以建设性的方式“批评”人们，而他们也会对您这样做。

很明显，只要您使用相同的拼写，例如在引用变量时，编译器就不会在意拼写错误。然后，问题就变成了拼写错误是否会对团队成员维护代码的能力产生负面影响。

我能看到的唯一方法是与进行维护的人员交谈，您可以从询问是否有人更费劲地遵循包含拼写错误的代码开始。

我认为没有任何方法可以完全消除此问题的主观性，但是要减少主观性，您可以（手动或通过脚本）扫描源代码，以获取特定代码模块的估计错误拼写次数，并查看是否需要维护与那些拼写错误较少的模块相比，拼写错误数量较高的模块平均花费更多的时间。

当然，并非所有模块都相等，因此您可以考虑使用各种度量标准加权结果，例如模块的圈复杂度。

以我的经验，这种基本的拼写错误令人不安，并且可能是更深层问题的征兆。我从事的每个项目都存在类似的“琐碎”错误，它们在设计中确实存在实际问题，这些问题以某种方式使其通过了审核过程，直到在开发过程中才出现，而这并不是当您想要发现真正需要的关键功能时不在那里。

我会仔细检查系统的规格（如果存在）并检查整体设计；如果您发现一些漏洞，我不会感到惊讶。

这实际上是两个独立但相关的问题。这取决于拼写错误的位置：

1）在源代码中。如果您有一个类似的标识符ArgumnetCount，当有人出现并使用正确的拼写时，可能会造成真正的问题。因此，您应尽可能纠正这些错误。如果需要保持向后API兼容性，则可以执行以下操作：

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2）以人类可读的文本形式（电子邮件，文档，代码注释）。正确编写这些代码很重要，但是我要说的是优先级较低，因为您脑海中的解析软件要宽容得多。如果您看到有一些错误的文本，但仍然可以阅读，那么不必担心-这不是您的问题。但是，如果有人向您发送一些自由联想的废话，并希望您将该废话用作多用户Web应用程序的蓝图，那么您应该向作者发送礼貌的说明，要求澄清（例如：“您笨拙的笨蛋，怎么办？您希望我理解这种情况吗？”）

正确的英文拼写是必须使用的代码。我也有一个很大的代码库，里面满是乱码，这是维护的噩梦。

不要让它失控。尝试教育每个人，代码维护者都不是读者。

好吧，这是一个多方面的文化问题。

从德语角度讲：我们注意到自己的语言越来越受到英语术语的影响。甚至有带有英语口号或广告的国家公司。同时，有些人，特别是在管理职位上的人，显然只能说一句普通德语。他们的演讲充满了嗡嗡声和难以理解的管理语。我们说这些人在说“英语”。

考虑到这种情况，英语尤其是在软件行业中，英语是“通用语言”，不可避免地，英语本身会受到大量非母语人士的影响。但是对于以英语为母语的人来说，这要比说汉语要好得多，才能参与软件行业。

是颜色还是颜色？其英文版本做你认为正确？一个人正确的拼写是另一个人打赢一场战争的借口。

如果您想发动战争，请仔细挑选自己的战斗并赢得胜利。在您的情况下，不必担心注释，不必担心内部问题，并且（几乎）完全专注于API的

我有个格言：整洁的代码不一定意味着整洁的头脑，但是正面肯定是正确的：不整洁的代码，不整洁的头脑。

不花时间正确命名变量和正确拼写注释的程序员几乎肯定不会花时间正确地做其他事情。程序员是否讲英语为母语并不是一个真正的问题，因为可以（并且应该）在同行评审中解决与英语有关的问题。

是的，对于产品，团队和个人而言，这都是一个严重的问题。

• 对于产品：更正可能会引入仅由客户发现的缺陷
• 对于团队而言：团队花费时间修正草率的编码，而不是创造价值
• 对于个人：拼写错误会使您看起来很愚蠢，并降低您在同行中的专业地位。