在查看同事的代码时，我遇到了一些函数名称上的拼写错误，以及语法错误，例如doesUserHasPermission()而不是函数和变量名称中的doesUserHavePermission()。

我应该指出这些是他还是我因为注意到这些而太学究了？

评论

我可能会小心，如果该人不是他们的第二语言，那么他实际上会需要英语的帮助。有些人满足于知道自己不具备表达结构化思想的能力，只是不具备正确的英语能力。如果英语是他们的母语，那是的，我认为语法不好是一个问题。
是。当您使用拼写错误的API时，它的确令人沮丧。它像野火一样蔓延。因此最好尽快进行纠正。
@Rei：在专业环境中，英语是否为母语是无关紧要的；如果这对他们来说不是太糟糕，但这不是借口，则应遵循相同的标准。
@Rei，由于这个原因，我看到的很多编程工作都需要熟练掌握母语。能够讨论需求，设计，规格和构造对于整个软件产品都非常重要。
HTTP-Referer经常困扰我。 zh.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_referer

#1 楼

带有拼写和语法错误的代码是无法维护的。


人们不会记得不好的语法，因此他们将尝试调用应编写的函数，这就是错误的方式
如果您不知道其拼写方式，就无法在代码中重复某些内容。
大多数进行语法/拼写检查的人这样做的不一致，因此他们会引入许多不匹配的错误命名。在不需要使用变量之前明确声明变量的语言中，这尤其成问题，因为您可以引入新的拼写，并且您的代码也不会停滞不前，让您知道自己搞砸了。

解决这些问题不是徒劳的，也不是主要由他人对自己的才智，识字等的看法所必需的（尽管这是一个很大的副作用）；这是关于编写高质量，可维护的代码。

评论

+1有时候，保持某人的感觉很重要，但是当它是代码审查时……如果您发现了它，那么发表评论是一个公平的游戏。我的公司使用坩埚进行代码审查，这使所有审查都可以看到它已被捕获，并允许审查者将其标记为不是缺陷，而是样式。

–opello
2010-12-28 6:26
+1-一旦拼写和语法错误进入了API，它们几乎不可能再次出现。我花了三年的大部分时间来写“ Avtivity”而不是“ Activity”，这样做总是对身体造成伤害。

–约翰·博德
2010-12-28 15:40
不论好坏，良好的编程习惯通常都归结为学究。另外，我想找到在原始HTTP规范中拼写Referrer并把他踢到脚踝的人。当然，可能是伯纳斯·李，所以之后我会感到内...。

–马尔沃里奥
2010-12-28 20:17


@Stephan Furlani：这就是我要提出的观点；它是我们不拥有的API的一部分。我们无法最终修复它，并且修复它的过程非常冗长且冗长，以至于没人愿意弄乱它。

–约翰·博德
2010-12-28 21:01
@John Bode，我想您应该已经创建了包装函数：) C＃为此有一个巧妙的窍门（尽管我忘记了它的名字）。

–求职
2010-12-29 16:40

#2 楼

当然是。如果名称在语法上正确，则更容易记住它。试图记住名字和语法错误完全是另一回事。

#3 楼

不要在正式的代码审查中指出它们是缺陷。而是标记一个清单，然后与他/她私下讨论。对此尽可能地保持外交态度，只是“嘿，我注意到的东西，而我遇到了很多真正鄙视这种事情的人，他们认为这使程序员看起来粗心和草率。”

如果这是客户要查看的代码，则绝对必须对其进行更正。

对于您提供的示例，我怀疑它的开头是UserHasPermission，还有其他人告诉他，本地实践是dosUserBlahBlah（）而不是UserBlahBlah （），而他只是忽略了语法变化。

评论

说这是关于别人的看法的，这似乎并不重要。说实话-他们使代码难以维护和建立。

– HedgeMage
2010-12-28 5:19


@HedgeMage：我对这样的事情的个人经验是，有些人对他们认为自己是批评自己的事情非常敏感。更糟糕的是，如果您似乎要批评的人受到管理人员的喜爱，那么这可能会带来非常丑陋的政治影响。 （是的，我有伤痕来证明这一点。）而且我已经看到，只要代码有效，对于“有效”的某些定义，组织实际上并不关心这种事情。我个人的感觉是，如果您走得平缓，则有更多的机会修复它，而不会出现其他头痛。

– John R. Strohm
2010-12-28在5:31
@John我当然可以看到，糟糕的工作环境会迫使某人不得不像这样行走，但是如果这首先是一个问题，那就很糟糕。自我如此脆弱（以及一种允许他们恶作剧的工作场所文化）的人从一开始就不利于业务发展。

– HedgeMage
2010-12-28在5:37
大多数成熟的程序员都很好地接受批评。毕竟，那就是同行评审的目的（我们都进行代码评审，不是吗？）批判注释，函数名等的拼写和语法是完全可以的。这不仅反映了作者，而且反映了作者在他们的整个组织中。

–quickly_now
2010-12-28 5:56
我在这里同意HedgeMage的观点，如果您无法在代码审查期间指出这样的错误（尤其是当它们在客观上是错误的时，例如问题中的示例），那么您将遇到更大的问题...

–迪恩·哈丁（Dean Harding）
2010-12-28在5:59

#4 楼

自己进行更改。

希望您所处的环境中的代码“所有权”不是问题。如果您可以在源代码管理中访问该项目，则只需自己修复即可。如果您看到某个特定的同事一致地犯相同类型的语法或拼写错误，则可能要指出这一点，但这取决于您的关系，此人是否是说英语的人，以及他们的总体接受程度。但是，无论您是否决定这样做，都请静静地进行修复。我会一直这样做，如果我看到错字，尤其是在方法签名或公共属性中，我会解决它。有时候，我什至无法抗拒在评论中修正拼写错误的诱惑，但这只是我自己:)

评论

然后您发现您刚刚破坏了第三个人的代码。您需要尽快解决这些问题，而不仅仅是在第一个家伙检查完所有内容之后才可以解决。

– David Thornley
2010-12-28 15:14
如果您担心对任何一段代码的修复都可能破坏“别人的”代码，并且您无话可说，那么您遇到的问题比拼写大。

–Cornel Masson
15年9月30日在11:56
@CornelMasson：并非如此。这是设计API的关键部分。

–轨道轻赛
16年1月4日在1:48

#5 楼

我是一名母语不是英语的开发人员，实际上是荷兰人，根本不介意有人指出我语法或拼写错误。这样，我可以不断提高我的英语水平。纠正所有源代码中的所有错误当然并不难。可以轻松编写一个简单的Perl脚本来循环遍历文件夹中的所有文件。也许甚至可以用sed完成？我不知道。

所以我当然会指出别人代码中的语法或拼写错误，但前提是我绝对确定我所说的是正确的。

#6 楼

我想在这里值得一提的是，HTTP协议中的HTTP Referrer标头被误称为“ referer”（并且我们必须使用它/已经学会了使用它。）:)

评论

而且我们再也不想看到这种事情了。

– David Thornley
2010-12-28 20:54

#7 楼

我同意其他答案，即存在语法错误的代码是无法维护的。

我还想补充一些内容：


代码通常是由谁编写的英语说得不太好和/或英语不是他们的母语。如果您检查的代码中有语法错误，这并不意味着您的同事犯了此错误。也许这只是网站上的复制粘贴。
如果英语不是您同事的母语，那么告诉她/他关于此错误的信息可能是一个好主意，也可能是一个很糟糕的主意。我来自法国，我总是欢迎对我用英语犯的错误发表评论，因为这是我将来可以避免的唯一方法。另一方面，我认识几个人，如果您向他们讲述他们犯的语法错误，他们会感到非常受伤。
像约翰·R·斯特罗姆（John R. Strohm）所说，切勿公开进行。大多数人都会对此感到非常恼火。


评论

“也许只是网站上的复制粘贴。”然后，复制它的人应该已经发现问题并解决了。逐字复制并留下错误比自己编写和创建错误同样糟糕。 “我知道有几个人，如果你告诉他们他们犯的语法错误，他们会感到非常受伤。”在业务中，我们每个人都应表现为成年人和同事的齐心协力，以实现共同的目标。提出问题的人需要使用机智，受到批评的人需要接受并从中发展。

–锡人
2010-12-28 7:21
我100％同意，作为专业人士，我们应该表现得像成年人，而不是个人。但这绝对需要指出和纠正。是的，应该使用机智，并且应该根据个人情况采取相应的方法。但是，如果您在鼓励完全避免该问题的环境中，也许是时候离开了。这将导致环境中毒。

–马克·弗里德曼
2010-12-28 13:50
任何拼写错误都可以通过简单的Google搜索来检查

– JoelFan
2010-12-28 20:56
如果您在向他人指出语法错误时感到受伤害，那么他们应该受到伤害。如果他们有诵读困难，他们应该告诉你。在这种情况下，我会悄悄地纠正错误；指出它是不必要的。

– gnasher729
20 Jan 24'8:50


#8 楼

我建议使用带有内置拼写检查器的IDE。 IntelliJ Idea在Java程序方面做得很棒。它捕获了许多令人尴尬的错别字，不仅在功能名称方面，而且在例如用户看到的异常消息。产生充满错字的消息的程序并不能激发很大的信心。

#9 楼

仅在


会影响程序的使用
会影响程序的准确性
我明确地知道作者希望得到纠正。

作为一个补充说明，如果您的函数名称足够长而无法使用语法，则它们可能太长。在给定的示例中，我将调用函数userHasPermission并将“语法”移至您的代码中，如下所示：

if userHasPermission() ...


评论

但是，语法错误的可能性仍然相同，因为在这种情况下，userHavePermission（）将是错误的。

–迪恩·哈丁（Dean Harding）
2010-12-28 8:44
但这就是重点！ userHasPermission（）表示由于语法〜OR〜而返回布尔值，这可能表示它设置了用户权限。 （Officer具有桥::用户具有权限）。还是模糊的。

–斯蒂芬·弗拉尼（Stephen Furlani）
2010-12-28 14:23


虽然我同意Q中的示例名称不必要地长，但我对“太长”的概括提出了警告。在这种情况下，该概念可以用更少的词来表达，因此应该缩短。但是，“太长”是什么？是否有字符或字数限制？

– Lance E Sloan先生
16年8月8日在15:07
如果将值与userHasPermission比较，DosUserHavePermission将不添加任何内容。另一方面，userPermission尚不清楚。

– gnasher729
20年1月24日在8:48

#10 楼

这在我的项目中也发生过很多（由希伯来语，俄语或阿拉伯语为母语的人居住），但甚至达到了更高的水平-我经常看到代码使用一些晦涩的术语，而这些术语恰恰是字典翻译成的作者的想法，与它们的含义无关...

就个人而言，这种情况如此频繁地发生，并且有如此多的团队成员甚至在我之前就已经编写过代码加入该项目后，我往往会忽略它，因为这无关紧要。

但是，如果我要与早已编写的代码或注释在同一文件中提交某些工作，并且他们有错别字，我会改正它们，只是因为这没太多工作。

#11 楼

黄金法则适用于


对别人做就象对他们一样
对你做对。


我希望别人对我有所帮助在这种事情上，所以我会帮助别人。
仁慈和支持对您有利。

评论

含糊不清-1-我不知道您正在建议提问者做什么。

– HedgeMage
2010-12-29 18:27
@HedgeMage，我建议OP申请en.wikipedia.org/wiki/The_Golden_Rule

–kevpie
2010-12-29 19:59
我很熟悉除了显然是愚蠢的（没有理由认为爱丽丝想要被对待的方式就是鲍勃想要被对待的方式），它还分散了真正的问题：创建好的代码。当然，我不会对此感到讨厌，但是我不会基于是否编写错误代码的人是否希望提出技术问题而提出建议！

– HedgeMage
2010-12-29 21:21
我认为@HedgeMage的抱怨可以用这样的方式说明：我希望代码在可用的时间和资源允许的范围内达到最高质量，因为我关心项目以及我今后的工作。鲍勃（Bob）希望避免对可纠正的错误进行批评，因为他没有很好地接受批评。我们将以完全不同的方式实施“黄金法则”。

–失明
2014年1月12日下午4:46
该建议意味着，OP将按照他的意愿进行操作。不要对待鲍勃如何对待鲍勃。我鼓励OP纠正Bob，因为他（OP）想针对相同的错误进行纠正，特别是在OP共享的情况下。

–kevpie
2014年1月13日下午5:04

#12 楼

这是代码中的一个小错误，但是是一个错误。像对待其他任何错误一样对待它。我的政策始终是假设我的同事有能力，并以这种方式对待他们，直到他们证明不是。

如果是单个错误，我可能会对其进行修复并检入。如果是一种模式，我可能会开始请该同事审查这些修复。让他们知道您认为他们是一个很好的编码人员，但这将是值得改进的地方。我不认为我会为这样的事情做很多事情。

，只要您不把它当作一个大问题，就应该很容易地把那个同事处于无需改善自我就可以改善的位置。

#13 楼

当然可以指出，但不要浪费时间检查拼写错误。
使用工具在CI上自动执行此操作。
在.net上，fxCop可以执行此操作...

#14 楼

它在很大程度上取决于错误的种类，错误的普遍程度和严重程度，以及它实际上是真正的错误，还是仅取决于您的措辞方式。

当一些白痴将5分钟的代码审查拖到半小时时，我个人无法忍受，因为他希望将所有内容重命名为自己的方式，而所有评论都只是因为他喜欢而改写坚持不懈。不需要将“正在加载数据对象”的日志行更改为“数据对象加载器组件现在将从数据对象存储组件加载相关的数据对象”。

/ rant :)

评论

坚持我的方式是一回事。坚持认为事物使用正确的拼写和语法完全是另一回事。

– David Thornley
2010-12-28 20:54
不能完全确定为什么我的回答不值得一提，但没关系...另外，我对David的评论的答复去了哪里？无论如何，在开发中并不总是希望100％正确的英语语法。在我上面的示例中，“加载数据对象”不是完整的句子，但这是二者中更可取的措词-简洁，易于本地化并且不占用太多空间。

– JohnL
2010-12-29 14:00

#15 楼

与许多其他良好的编程习惯一样，在程序中实施拼写政策的唯一客观，非政治且有效的方法是，在预提交过程中将其自动化。即使您必须为此目的编写自己的工具，自动化也可以使您免于大量不满。

评论

许多最重要的错误无法自动捕获。这也适用于拼写和语法。您可以进行自动检查，但结果必须等同于警告。这是因为拼写检查器会同时产生误报（例如专有名词）和误报（也有两个to）。因此，必须进行手动干预。

–马修·弗拉申（Matthew Flaschen）
2010-12-28 21:38


那种自动化并不能解决这些问题，它只会捕获人们犯的一些错误。

–明白了
2010-12-28 22:54
自动更正???互联网上有许多自动更正“失败”的示例。那绝对不好。

– Florian F
16年1月4日，下午2:35