例如，在JS中有一个通用的代码段可以获取默认值：我的团队，他们的JS级别很低。
那我不应该使用这个技巧吗？根据任何JS开发人员的说法，它会使代码更难被同龄人阅读，但比以下代码更具可读性：
，那么他们可以学习一些东西。但是通常情况是，他们认为这是“试图变得聪明”。
那么，如果我的队友的级别低于我，我应该降低代码级别吗？
#1 楼
好的，这是我这个大而复杂的话题。保持编码风格的优点：
x = x || 10之类的东西在JavaScript开发中很常见，并且提供了一种一致性在您的代码和您使用的外部资源代码之间。更高级别的代码通常更具表达力，您知道自己能得到什么，并且容易被训练有素的专业人员阅读。
您会喜欢工作的更多。我个人很看重创建漂亮的代码。我认为这给我的工作带来了很大的满足感。
通常，它会创建更具可读性的样式。坚持使用语言的习语可能非常有价值-出于某种原因它们经常是习语。
保持编码风格的缺点：
低级程序员要跟上。这些人通常是维护您的代码的人，而这些人实际上必须阅读您编写的内容。
代码的维护者，通常JavaScript代码来自其他语言。您的程序员可能会熟练使用Java或C＃，但不了解JavaScript的方式和时间完全不同。这些要点通常是惯用的-立即调用的函数表达式（IIFE）就是这种构造的一个例子。 。您应该渴望编写具有表现力，清晰简洁的代码。如果您对团队水平有任何疑问，请对他们进行培训。人们乐于学习，远胜于您的想象，并在确信新的构架变得更好时愿意适应新的构想。愿意承认有时您错了，无论如何，请尝试在整个工作环境中保持样式的一致性。这样做有助于避免敌意。
最重要的是保持一致。
团队的代码应像一个人一样编写。您绝对必须在编码准则上达成共识。您应该遵守那些准则。如果编码指南规定应该以“不太聪明”的方式读取可选参数，那么就是这样。
评论
我知道学习是一回事，但这真的是开发人员培训他的同事的工作吗？寻找最适合他们的培训确实是管理层的工作。
– corsiKa
13年7月3日在14:38
@corsiKa这些开发人员不太可能通过“付费培训”来学习某种语言的所有特质（即，培训管理人员会派遣人员去的那种培训）。当同事之间相互学习时，我认为这是一个病态的工作场所。并不是说OP必须给他们提供课堂培训。人们只能在遇到困难时提出问题，正如上面的评论中提到的那样，代码审查可以很好地共享这种知识。
–金属迈克斯特
13年7月3日在17:40
他的同事应该从OP（和其他人）设定的示例中自己学习。否则，他们将永远无法超越自己的现有知识。 OP不必每天花几个小时来亲自培训他们，但是代码审查和不定期的袋装课程可以为每个人（嗯，就是每个想要学习的人）提供帮助。
– alroc
13年7月3日在17:40
@corsiKa同意，对高级开发人员的代码进行审核本身并不足以进行培训，尽管这可能是识别初级开发人员以后应查找的内容的好方法。
–丹·里昂斯
13年7月3日在18:45
@yms很公平，这是一个有效的观点。我从不认为可读性为王。我强烈反对使用多种语言，就像它们是同一语言一样。在数百小时的调试中“赢得”了异议。尽管我完全同意可读性为王，但我相信您不能以类似的方式对待几种语言的代码。而且，我认为JavaScript的大多数“不良声誉”就是因为这一点。人们期望它表现得像其他语言，但事实并非如此。我同意可读性是关键任务。更好的代码总是更具可读性:)
–本杰明·格伦鲍姆（Benjamin Gruenbaum）
13年7月4日在19:53
#2 楼
好吧您是否应该降低代码的技巧？不一定，但是您绝对应该提高评论的技巧。确保在代码中包含良好的注释，尤其是在您认为可能更复杂的部分周围。不要使用过多的注释，以免使代码难以理解，但请务必使每个部分的目的明确。
现实是，注释稍冗长可能对技术水平较低的团队成员有用，但是技能最差的人会忽略它们，尤其是如果太多，那就不要过度使用。围绕每个变量默认值的注释将非常难以维护和阅读。相反，应该将样式或重复的快捷方式或代码模式确定为标准。如果您认为这种形式的参数默认值应该为所有人所理解，并且每次都应使用，请将这些想法写下来，并带给您的团队负责人。可能只有一次简单的会议，就可以教会您的队友，在会议上讨论您提出的标准。
正如已经回答的另一个答案，请保持一致。 />教队友可能是您可以帮助每个参与人员的最好方法。明确指出，如果有人对某个代码段有疑问，并在提交日志或时间戳中使用您的姓名，那么他们应该随时向您询问。如果您的团队对代码进行了审查，那么这是一个很好的机会，可以向您的队友解释任何可能引起混淆的注释。如果您的团队没有代码审查，为什么不呢？来吧！
但是您需要小心。您可能并不总是在教别人，甚至可能忘记了在给定的代码部分中最初试图做的事情。
“聪明”的技巧
牢记队友的能力绝对重要，但是编写可维护的代码通常意味着不使用奥秘的捷径来解决可能具有更常见解决方案的问题。即使您的队友很聪明，这也很重要。您不希望使代码花太长时间来掌握或产生可能遗漏的细微但重要的副作用。通常，在有合适的替代方法时，最好避免使用“聪明”的把戏。您永远都不知道谁可能需要一直维护代码-很多时候我们自己的旧版本不记得这些技巧的细节或原因。
吻
如有疑问，请保持简单。代码是否简单，不一定像您想的那样对应于程序员的技能。实际上，一些最出色的解决方案是最简单的解决方案，而某些更复杂的解决方案最终出现在TheDailyWTF上。保持代码简单明了可以使一些更明智但可能违反直觉的决策更易于掌握。
评论
问题在于，即使我认为显然不是，语言功能也被视为“聪明的把戏”。见过关闭吗？见过IIFE吗？有没有看过作为回调传递的函数引用？这些是每位经验丰富的JS开发人员都知道的语言功能。但是，对于经验不足的JS开发人员来说，它们是“聪明的把戏”。
–弗洛里安人造黄油
13年7月3日在8:21
@FlorianMargaine在我看来，您需要更改术语，即：这些不是“聪明的把戏”，它们是语言的更高级功能... 1表示您的代码不容易理解/不好2意味着学习和提高“我的”编码技能的机会（如何使他人改变其术语？评论，鼓励问题，分享解释这些功能的代码文章，等等）
–安德鲁·比克顿（Andrew Bickerton）
13年7月3日，11：19
如果它减轻了您的任何头痛，则部分沮丧可能是Java语言作为一种语言……没有任何意义。在美国的人们都觉得这很有意义，因为我们已经做了很长时间了。但是，无论我们如何使语言能够“正常运行”，从中立的角度来看，这都是没有意义的。另一个注意事项;令人遗憾的是，您可能正在展示雇用经验丰富的开发人员的价值，或者最好是聘请愿意学习新范例的“任何语言”开发人员。
– Katana314
13年7月3日在13:16
@FlorianMargaine我也主要从事JavaScript工作，我知道您的痛苦。我通过尝试教育队友来解决这个问题。 Crockford JavaScript视频（1、2）帮助。我不认为您列出的那些东西属于“聪明”的把戏，您的队友应该学习这些技巧，但是您使用这些语言功能所做的某些事情可能是“聪明”的坏种类。如何说服您的公司聘请经验丰富的开发人员可能完全是另一个问题...
– Corion
2013年7月3日14:48
评论并不总是很好。我读过一段时间的“清洁代码”，他对评论的一些观点非常出色。如果您需要编写注释来解释您的代码，则很有可能代码编写错误。如果代码更具表现力，则注释是多余的。每次您要发表评论时，请停下来思考一下重构是否是更好的选择。如果代码具有表达力，则无需解释其用途。此外，如果更改了代码，但注释未进行更新以匹配，则注释可能会引起误解或完全错误。
–帕帕
2013年9月8日在18:09
#3 楼
在JS中创建函数似乎有很大的反感。这种厌恶感使人们试图变得聪明，并使用荒谬的技巧来将内容保持在函数调用本来的样子。当然，调用中的函数
名称也充当了额外的文档。我们不能在棘手的表达式上附加注释
，因为那样会破坏这样做的意义
，因此我们将其称为“ js惯用语”，突然就可以理解。
Javascript非常易于访问，大多数人不像我们那样吃早餐的规格。因此，他们永远不会理解成语的隐藏假设和边缘情况。
它是默认值的惯用法。两者都是有害的，实际上后者更为有害。他
不会理解这里的假设和极端情况。他不在乎阅读规范并永远理解它。 br />还会隐式地将
null，undefined，+0，-0和NaN视为不合适的值。我必须记住从现在起3个月需要更改时，我可能会忘记它。” 。
隐式假设很可能在将来引起错误，并且当您的代码库中充满了诸如
这样的技巧时，那么您就没有机会在任何时候都将它们牢记在心您正在考虑修改会影响什么。这是针对“ JS专业版”的，即使要求是从一个虚假的值开始的，一般的joe也会编写该错误。
您的新代码段更加熟悉语法，但仍然存在上述问题。
您可以选择：
x = x || 'default_value';
现在，您可以使用非常复杂的逻辑来处理极端情况，并且客户端代码仍然看起来漂亮且可读。还是像
false这样的聪明技巧？聪明技巧始终在某些隐藏的假设下运行，这些假设在最初创建代码时会被忽略。我
无需将IIFE修改为其他任何东西，因为需求已更改，它将始终存在。也许在2020年，我可以使用实际模块，但是是的。
""或用于地板的货物崇拜版本|| "default"假定正数和32位有符号整数界限。 /> | 0假定所有伪造的值都等于根本不传递任何参数。等等。
评论
您只关注一个示例。使用IIFE，闭包，函数引用之类的东西怎么办？这是我的问题的重点。
–弗洛里安人造黄油
13年7月3日在13:23
@FlorianMargaine您认为我在第二部分中所说的不够好吗？
– Esailija
13年7月3日在13:24
好吧，这并没有说明如何处理我只是使用“高级语言功能”的情况，因为这种情况使队友误解为“聪明把戏”。
–弗洛里安人造黄油
13年7月3日在13:26
我喜欢这个答案+1，我认为它漏掉了大部分问题，但它深入讨论了其他部分和场景，并解释了其他团队开发人员在没有阅读您的指导的情况下自行选择此类概念的问题码。
–本杰明·格伦鲍姆（Benjamin Gruenbaum）
13年7月3日在13:27
@FlorianMargaine您的意思是如何在使用IIFE的工作场所中实际处理实际情况，有人认为这是一个聪明的把戏？正如我所解释的那样，由于没有隐藏的假设，因此对于“平均值”来说，“变量将不会是全局变量”这样的记忆就可以了。
– Esailija
13年7月3日在13:31
#4 楼
您不应该降低编程技能，但是可能需要调整编写代码的方式。几乎最重要的目的是使您的代码对必须阅读和维护它的人员明确。不幸的是，对于任何特定样式是“聪明”还是仅是高级用法，可能需要一些判断。问题中的代码就是一个很好的例子-您的解决方案不一定比另一个更好。有人会说是，有些人会不同意。由于这两种解决方案实际上都具有相等的运行时性能（请阅读：用户永远不会知道两者之间的差异），请选择整个团队最适应的风格。
在某些情况下，您需要教他们更好的编码方式，但是有时为了清晰起见，您需要妥协。
评论
+1。 OP给出的两个具体示例在经验上都没有比另一个更好，它们只是不同。
–罗斯·帕特森（Ross Patterson）
2013年9月7日13:19
非常好的答案@ bryan-oakley。干杯
– Andy K
17年9月14日在9:54
#5 楼
这可能已经在另一个答案中说过了，但是我想按照我自己的命令回答这个问题。 。您的听众是您团队的开发人员。不要编写没有正当理由就无法理解的代码。将会维护它的开发人员。 （警告：糟糕的做法就是仅仅因为它们当前在代码库中而遵循不良模式。）如果您找到使用目标用户不易理解的语言特定习惯用法的充分理由，一条评论。如果发现需要在每行中添加一条注释，则可能需要重写代码以使读者更容易理解。对于惯用语，我认为惯用语没有什么价值。
特定示例
我们的代码库中有大量的perl脚本。通常，我们仅将perl用于非常简单的操作，并且绝大部分代码都是由Java开发人员编写的，因此其样式非常类似于java。我们有一套perl脚本和一个由“ perl专家”编写的框架，此框架后来离开了我们公司。该代码包含许多更晦涩的perl惯用语，而且包括我在内的我们所有开发人员都无法毫不费力地阅读此perl代码。我们经常为此诅咒他。 :)
#6 楼
如果您编写了不错的代码，但是您认为您现在或将来的同事可能会很难遵循该代码，则应添加简短注释以对其进行解释。这样，您可以教他们一些东西而不会侮辱他们的个人智慧或在小组讨论中使任何人尴尬。
#7 楼
我不会将您的示例称为a俩，而只是习惯用法。是否应该使用它，恕我直言不取决于您团队的当前水平，而是（至少有一些）您的队友是否愿意学习一些新习语。当然，您应该与他们讨论此主题，而不要对他们实施这种样式。而且，您不应该要求他们每天学习5项新事物或“技巧”。但老实说，如果您只有队友不愿意学习新的东西，即使它比这个习语简单又小，您也应该考虑改用其他团队。#8 楼
阅读这个问题以及随后的答案和讨论似乎有两点。第一个：可以使用高级语言功能吗？第二个：如何在没有出现“炫耀”的情况下做到这一点？例如：在C＃中，您不必使用Linq或Lambda表达式，但是大多数人会这样做，因为一旦您真正知道它在做什么，它就会使代码更整洁并且更易于理解。起初看起来很奇怪。人们习惯了模式，在许多情况下，人们使用固定的工作方式只是为了完成工作。我和下一个男人一样感到内。我们都有截止日期。在某些方面，您有引入新思想和新思维方式的罪恶感！这是第二点，这可能是您遇到最大阻力的地方。工作？快吗因此，如果您的方式没有性能优势，那么在给出的示例中就没有正确或错误的方法。您的方式是否使代码更具可读性？一旦您的同事习惯了，它可能就会起作用。
那么，您如何介绍这些更改？尝试按照以下方式与您的同事进行讨论：您是否知道可以用这种方式编写此功能？代码审查和结对编程可能是允许想法“异花授粉”的好时机。由于不知道您所使用的环境，我对要做什么规定非常棘手。我发现有些程序员可能非常防御并且抵制更改。我再次对此感到内gui。与这类程序员一起工作的最佳方法是花一些时间来学习使他们产生兴趣的东西，了解他们的背景，然后将自己的风格和经验与他们进行比较和对比。这需要时间，但要花费很多时间。如果可能，请鼓励他们。
评论
如果您认为在C＃环境中证明自己的意思会更容易，我怀疑OP不会介意-我肯定不会。这个问题不是关于JavaScript的：)想象一下放弃代码中的可选参数或lambda，因为其他团队开发人员不理解它-您会这样做吗？我认为您在这里提出了一些有趣的想法，但是如果您不再担心特定的语言，可以用一种更具吸引力的方式编写它：)
–本杰明·格伦鲍姆（Benjamin Gruenbaum）
13年7月10日在20:22
我主要使用C＃工作，因此这是最容易想到的示例。关于我是否会因为其他人不了解有用的语言功能而放弃它们，您的确提出了一个极好的观点。答案肯定不是，但是当然棘手的一点是让其他人看到这种新方法的优点，这似乎是Florian的主要问题。
–丹尼尔·霍林拉克（Daniel Hollinrake）
13年7月11日在8:55
#9 楼
那就不要去皇家McBee计算机公司工作，因为谁能说您不是没有经验的程序员。当然，编写简洁明了的代码非常好，它可能在javascript环境中很有用（嗯，直到有人生产js编译器以下载到浏览器，但这是另一回事了。） />
但是重要的是，您的代码可以保留编写几分钟的时间。当然，它既快速又容易，您可以将其分解并继续进行，但是如果多年后又不得不回到它，那您可能会想到“哪个木偶写了这个”，而意识到是您！ （我这样做了，确保大多数人也这样做了。老实说，我怪罪过分苛刻的截止日期）。 -与特定的操作员一起工作（如果它可行且清晰），以及您的“经验不足”的开发人员（尽管这对他们是贬义的，我知道很多经验不足的开发人员都知道所有操作员和技巧，因为他们记住了各种网页教程和参考资料，即使他们知道每一个小技巧，他们也会写出最糟糕的代码。。。可能不仅仅是巧合了。
无论如何，如果您能阅读梅尔的故事，您会即使Mel是真正的第一手程序员，也要意识到这些技巧并不是放入任何代码中的最佳方法。有人说自己可以编写出色的代码，而其他所有人都需要学习更多以跟上发展的步伐，这是无可厚非的。
评论
我不知道有一个程序员没有回到他们的代码（从一个月前开始！）并去了“谁写的”。我们总是在风格上发展（至少我们尝试）。在这种特定情况下，OP正在编写标准代码，而不是WTFish代码。 OP不在讨论编写“聪明的”代码或“简而言之”的代码，它是惯用的JS。
–本杰明·格伦鲍姆（Benjamin Gruenbaum）
2013年9月11日上午10:07
#10 楼
好吧，对于初学者来说，对我来说看起来像是基本的JS。但是总的来说，您不应该使用聪明的技巧来解释“调试的难度是编程的两倍。如果您编写的代码尽可能聪明，那么按照定义，您将无法调试它”。
这并不意味着您应该仅仅因为别人不理解它而避免编写代码-应该以尽可能清晰，一致的方式编写代码。但是您的明确判断标准应该是“我一年会读一遍就能理解这一点”，而不是“任何人都可以理解它”。其他人正在努力提高自己的技能-不要让自己受阻，以免给别人一些假想的麻烦。
#11 楼
我会与我的队友讨论我们想要什么样的编码标准，因为这主要是关于应该如何以多种方式完成代码库的工作。如果达成共识，这将是我最初尝试的答案。管理层和一些团队已将其清除。这里的想法是确保管理层对这个想法感到满意，并且我不仅要自己做自己的事情，然后强迫其他人都接受它。这更像是您的团队拥有什么样的标准和实践的问题，而不仅仅是技能水平，因为有许多评估代码的方法。别人能否保持它是这些标准之一。#12 楼
问题是您希望源代码具有良好的可读性，但是可读性在旁观者的眼中。我建议我们需要更好的工具来解决此问题。请注意，没有什么复杂的，我们拥有超过50年的技术可以做到这一点。在编辑器中包括一个解析器，并让编辑器以六边形的形式保存源（是的，就像lisp一样）。然后阅读源代码，编辑器将其解析为语法和印刷形式（您知道空格，制表符和逗号），形成用户喜欢的形式。程序员会将其读为
if (0 == x) { x = 10;}
emacs可以轻松完成所有任务。
评论
在这种情况下，我们知道谁是情人。他们是我们的同事。我认为当您不认识听众时，通常会使用该词组。
– dcaswell
2013年9月8日0:18在
#13 楼
而不是笨拙地编写代码，为什么不提高团队质量呢？培训，指导，教育和改善的雇佣实践可以对确保持续改进起到很大作用。当然，在您展示的特定案例中，您只是试图变得聪明而刻意编写模糊的代码，这绝不是一个好主意。代码首先应该是易读的，易于理解的，而不是为了显示您在尽可能少的语句中创建某些东西的聪明程度而编写的（特殊情况除外，如更多的语句会导致不可接受的性能下降，在这种情况下，称为大量注释for）。
评论
在这种情况下，我并不聪明。我正在为任何经验丰富的开发人员编写惯用代码。你知道我现在为什么挣扎吗？ :)
–弗洛里安人造黄油
13年7月3日在12:05
您的第一段是正确的，但为-1，因为第二段距离很远。说这个例子是故意的聪明举动是不准确的。这实际上非常清楚，更重要的是，这是许多优秀的javascript开发人员都认可的惯用风格。它不是javascript中默认函数参数的唯一惯用法，但它是常见的用法。
–李本
13年7月8日23:38
评论
我认为这归结为“您应该编写惯用的代码并强迫人们达到这个水平吗？还是写出明确表达所有内容的非惯用的代码？”不要降低代码的技能水平！通过阅读更高级的程序员的代码，我学到了很多东西。营造一种文化，如果您的同龄人不懂某事，就会鼓励他们提问（和学习）。只要确保您保持一致即可。
你有代码审查吗？对于他们来说，这将是一个很好的地方来询问有关此类代码的问题。
考虑到您的“听众”，编码技巧的一部分就是清晰度。这个特定的习惯用法似乎值得教teaching，但是在某些情况下，使用更加透明的编码风格会更加有意义。
只是意味着谁认为第二个例子的质量比第一个例子好，因为所做的事情很明确？似乎第二个示例比第一个示例的简写形式更具可读性。是否没有工具可以自动将人工创建的代码优化为Javascript？根据我的Javascript经验，运行的实际代码不一定要尽可能有效地运行。