为什么有些人认为聪明在编程中有害？

#1 楼

简单的解决方案更适合长期维护。这并不总是与语言熟悉有关。即使您是给定语言的专家，一条复杂的线（或多条线）也需要花费时间才能弄清楚。您打开一个文件并开始阅读：“好，简单，简单，明白了，是的，WTF ？！”您的大脑停止运转，现在必须停止并解密一条复杂的线。除非有一个可测量的，具体的实现理由，否则它就是“太聪明”。 。除了众所周知的方法之外，您还必须弄清楚创建“聪明”解决方案所需要的思考过程，这可能非常困难。

那，我讨厌避免使用模式（使用是合理的），只是因为有人可能不理解。作为开发人员，我们要继续学习，如果我们不了解某些内容，这是学习它而不是避免它的原因。

评论

---

+1很好说。我认为这是平衡的事情。如果我可以期望某个知识渊博的人对自己有所了解的话就能理解该代码，那么您可以聪明一点，甚至可以添加一条注释。如果仅仅因为有人想证明自己的编码技能而花了四倍的时间来理解代码-不！如果某人足够聪明，可以提出一个聪明的解决方案，那么他们应该足够聪明，以决定它是否可以理解。否则，它只是在炫耀。

–安妮·舒斯勒（Anne Schuessler）
2010-12-10 17:21

---

我喜欢的最后一段。其余部分是正确的，但很不幸。

–Orbling
2010-12-10 20:51

---

看起来您已经看过Zend PHP的源代码:)

– Tim Post
2010-12-11 7:44

---

+1一个简单的模式可能不如一个聪明的模式执行，就像您说的那样，开发人员有责任继续通过理解它来推动“聪明”的发展，这取决于我们。

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

---

作为必须证明自己确实只是“最小，正交正确”而“聪明”地做某事的人，我想补充一点，到底什么才是聪明是有主观性的。例如，有些人总是想写出FuncX（）然后返回true，否则返回false，并且永远不会希望您只写return FuncX（）。我不是在开玩笑，我确实是在进行对话。因为人们想在某个地方挂断点之类的东西。 :-)

– Warren P
13年3月21日在21:05

---

#2 楼

KISS原则

保持简单，愚蠢。聪明的解决方案很棒，但通常最简单的直接解决方案是最好的。


“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，就定义而言，您就不够聪明，无法对其进行调试。”


Brian Kernighan

#3 楼

愚人无视复杂性；实用主义者遭受苦难；专家避免天才将其删除。
-Alan Perlis

#4 楼

最好的解决方案并不总是最聪明的解决方案。有时简单的解决方案同样会很好。

在软件中，您始终需要考虑可维护性。如果一段代码对于要维护它的人来说太聪明了，我会说聪明是不值得的。

#5 楼

引用Brian Kernighan的话：

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，就定义而言，您就不足以调试它。”

#6 楼

聪明是一种工具；它本身无害。它只会在不必要的情况下变得有害。

#7 楼

“聪明”在应用于代码时几乎总是对“不必要复杂”的委婉说法。

读懂清晰，简单的代码已经足够困难了。读“聪明”的代码就像重新研究拉丁诗。这种情况也可以看作是一个例子，说明为什么为真实的人设计软件很困难：因为它们模棱两可。

又由于某些程序员受苦于理解大多数人遵循的社交协议，因此禁止他们这样做直接将代码谴责为“不必要复杂”，他们可能会发现很难区分“聪明”一词的两种含义。与某些人的想法相反，我认为最终更好的“人”（意味着：有同情心，内省和耐心的人）可以成为更好的开发人员。因为他们知道为谁写。

#8 楼

大多数人都从“代码需要太多的解密才能弄清楚它在做什么”这一方面着眼于聪明，以及随之而来的所有不好的事情，例如


别人可以弄清楚它，更不用说对其进行维护/调试了。
写书的人甚至都不知道它做什么。 > etc ....

所有的优点，但是还有另一个消极的方面，那就是古老的自我问题。这会导致一些问题，例如“太聪明”的人无法使用其他人的解决方案。当您可以发明自己的方法给同一只猫剥皮时，为什么还要寻找别人做过的事情？
认为自己发明了解决问题的最酷方法的人通常会拒绝接受任何投入。
即使有明显的问题或需要微不足道的更改，也不会允许任何人修改“他们的”代码。但在将其滚动到系统的关键部分之前，无论是在个人项目还是在非生产代码中都无法很好地处理它。

有时候我们都对自我感到内，但是当它阻碍了团队的发展时，这就是一个问题。

#9 楼

良好的聪明-聪明的代码行与非聪明的选择中的行之间的比率很高。 20条代码使您免于编写20000，这是“极佳技巧”。 Good Clever可以节省您的工作。

Bad Clever －编写的代码行与保存的代码行之间的比率较低。避免编写五行代码的聪明行之一就是Bad Clever。坏聪明是关于“句法手淫”的。

只需要注意：坏聪明几乎从来没有被称为“坏聪明”；它通常会以“美丽”，“优雅”，“简洁”或“简洁”的别名旅行。

#10 楼

我想知道每个人对“聪明”的定义。

就个人而言，当我解决一个棘手的复杂问题并以非常简单直接的方式实施该问题时，我觉得自己很聪明保持可接受的效率水平。

tl; dr当我在代码审阅时说“哇，这比我想象的要容易得多”时，我感到很聪明。 “这就是wtf。”

#11 楼

除了列出的理论答案之外，通常在其他人都不太聪明的情况下使用此方法。

不考虑理论上的争论，过于聪明通常是基于技能最低的团队成员可以合理地工作的，因此这与环境息息相关。 />

#12 楼

有时我很聪明，以至于错了。

#13 楼

性能，可维护，及时和廉价是我衡量解决方案的方法。我想聪明的方法也可以作为解决方案的一部分，只要它不会对这些质量产生负面影响。

#14 楼

如果聪明的代码+使它易于理解的代码<=简单代码所需的注释数量，那么我说去聪明的代码。每次。

我认为，当人们写“聪明的代码”而故意不正确地评论它时，就会出现这个问题，因为只有通过最初的理解，以后的下一代才不得不花时间”欣赏”它多么聪明。

#15 楼

我想起了我曾经看到的一个引述给许多不同人的引语，因为引号经常是好的。

释义：


任何有智慧的人都可以使
简单复杂，
天才使复杂变得简单。


采取一个复杂的想法并将其简化，以便可以理解，这表明构造函数很聪明，但采取一个简单的想法使其变得复杂，则表明构造函数希望被视为聪明。 >

#16 楼

如果很难找到“聪明”的解决方案，那么就不应该使用它。例如，如果您通过副作用可以将复杂的计算压缩到一行，那么它就很聪明。但是如果别人花一个小时弄清楚你在做什么，那就太聪明了。

#17 楼

我认为，聪明本身不是问题。通常，我们会对“聪明”（没有讽刺）和“ insightfull”代码感到困惑。我看到的一个问题是，通常“聪明的”（带有讽刺意味的）代码包含隐式的不可见需求，这使得它随着时间的推移难以调试和维护。聪明的算法。 IMO是Quicksort的一种。网络连接，数据库等...）。

为了正确维护“聪明的”代码而必须负担的数据量通常很大，以具有良好的成本效益比。

#18 楼

“聪明的代码”是程序员必须认真思考或使用一些高级技能编写的任何代码。问题在于它忽略了一定的“机智余量”的需求，这是Brian W. Kernighan最能表达的：您尽可能聪明地编写代码，按照定义，您不够聪明，无法对其进行调试。”

#19 楼

因为对于开发人员来说，在创造力的爆发下看起来很聪明，可能只是一团糟，对于其他人来说，这只是一个难以理解，难以维护的困惑之谜。一堆谜语，但是如果您有经验，您通常会意识到，将其维持在中期或长期的过程中，将使您的企业（而不是您，开发人员）付出更多的代价。因此，您宁愿在开发人员被带走时安抚他们的热情。

当然，除了有足够的理由来证明聪明才智。并且，如果您刚刚编写的内容晦涩难懂，那么会得到一个很好的文档。您确实评论了这段聪明的代码，对吗？解释它的意图，为什么需要像它，以及它如何表现？如果需要15个级别的间接操作来完成简单的操作，那么您很有可能也属于先前的类别。如果没有记录，那就很麻烦。

好的代码不应该要求维护人员一直都花100％的时间来理解它。
好的代码很聪明。出色的代码几乎可以高效，但在许多其他方面却更好。出色的代码不要求具有15个视图的IDE即可遵循您的应用程序的设计。

注意：嘿，我写了一些我认为很聪明的东西，但这吸引了WTF吗？如果不是我的共同开发者，那就是我的经理的话。必须从他们的角度来看。

#20 楼

我倾向于聪明，但我会努力做到优雅。

现在开发代码，其他人将不再尝试，以后再回避。

#21 楼

根据我的经验和其他答案，这是我对问题的理解：


巧妙地编写但可读且可维护的代码并不有害。但是，大多数开发人员不会将这种代码称为“聪明”。他们可能会使用其他术语，例如“优雅”。关于此类代码是否存在，可能存在争议，也可能没有争议。 >一些缺乏经验的开发人员需要花费大量时间和精力的生产代码被某些人认为是有害的。我看到过任何一种答案，并且我与开发人员合作，他们明确表示他们希望保留所有内容“最低公分母”。

#22 楼

我认识一个人他可能是我见过的最聪明的人。他绝对是一个令人难以置信的编码器，就纯粹的编程技巧而言，可能比我一生都要出色。他就像在键入Word文档一样编写代码，并且可以像您不相信的那样反向链接列表。如果您想谈论编写一些非常复杂的代码，那么他就是您的助手，如果我遇到一个难以置信的难题，那么我总是向他求助。但是，与他一起在团队环境中进行项目工作实在令人发指。他无法直接针对业务问题，也无法提供合理，高效和简洁的解决方案。对他来说，列出1000行的代码比100行更好。他将使用自己的超级优化工具，而不是使用通过IDE或框架提供给他的工具。一切都很好，除了其他团队成员正在等待他完成某件事，或者我们有最后期限。

我很欣赏他做这些复杂事情的能力，但我需要的是有人可以解决问题并继续前进。不好说或承认，但是有时候在企业环境中，时间就是一切，您只需要解决问题并继续生活，您就可以稍后再回到问题上，并重构它来改善自己您的代码。聪明和屁股之间有一条细线。对于我的团队，我的座右铭始终是，在这种情况下可以解决的最简单的事情是什么，然后从那里开始。有时候，简单并非总是答案，但它是一个很好的起点。

#23 楼

在这种情况下，“聪明”的意思是“对自己的利益太聪明了”，即某种东西现在可以工作，但是以后将成为理解和改变的噩梦。编程语言的功能，或者利用怪异的副作用，或者是在目标语言中解决问题的一种真正奇怪的方法。

#24 楼

我更喜欢简单的解决方案，我真的很喜欢红宝石方式。例如，当您想对列表中的前2个元素求和时。首先，您将列表切成大小为2，然后将其求和。

我记得曾经使用1个列表而不是3个列表，并创建了一个很难维护/更改的大函数。

在当今世界，我们不必为了提高性能而牺牲代码的清晰度（除了c ++，他们不必这样做，但他们会这样做）。

#25 楼

通常，当您需要“聪明”时，可以解决代码中的问题。如果不是一种解决方法，并且不是很简单，那么在假定某些条件时（在编写代码时可能是100％正确的），您会得到很多困惑的面孔或其他怪异的副作用

因此聪明==令人困惑==不好:(
但当我将它们用于有限问题的实际解决方案时，它也很棒。

#26 楼

重新引用以获取上下文并更容易理解：


“调试是一开始编写代码的两倍。
因此，如果您编写代码的技巧很巧妙按照
定义，您可能不够聪明，不足以对其进行调试。“


Brian Kernighan在这里写的显然是指卷积，他错误地使用了聪明一词。 。


“调试是一开始编写代码的两倍。
因此，如果您尽可能以[convolulated]编写代码，
定义，不足以调试它。”


卷积：

A thing that is complex and difficult to follow.

聪明：

Showing intelligence or skill; ingenious

受过良好教育的程序员知道简单的代码是巧妙的。根据定义，尽可能聪明的代码应该很简单。受过良好教育的程序员也将避免使用和编写像瘟疫这样的复杂代码。只要有机会，他们还将把复杂的代码转换为聪明的代码。代码通常始于复杂的过程，并且随着经验和共享知识可以更好地理解编程领域的知识和对人类认知能力的理解，从而变得更加聪明。这个词的滥用在业界很普遍，会对社会产生负面影响，我很想看到这个人自己解决的问题。在写这篇文章之前，我试图看看是否可以简单地给他发电子邮件，但是，我找不到我理解的任何电子邮件联系信息：(。

我看到的负面社会影响是其他程序员排斥他们的聪明同事，因为他们现在把聪明视为一个问题。真正的问题是愚蠢的同龄人，他们认为自己以一种新的，独特的方式做事很聪明，并且在没有优势的情况下不断发明新事物，而不是获得和理解更大的社区并尽可能多地重复使用聪明的想法。

我确实需要澄清一下，尽管常常要获得理解比发明自己的要困难得多。由于工业界普遍存在不现实的截止日期问题，因此为较小的利基问题发明自己的解决方案将节省时间。这是基于以下观察：有用的，可重复使用的事物通常以更大的利基为目标，或者为发明提供有用的抽象。这也是基于这样一个事实，人们瞄准大型利基市场来赚钱，而这往往使该工具极难使用，因为要使某物可用于广泛的应用程序涉及到复杂性。

另一个负面的社会影响是，这阻碍了进步和理解的欲望，因为在我们这个以自我为中心的世界中，我们将立即否认自己缺乏理解，并写下令人费解的代码，即使一旦理解，这个想法就是实际上非常聪明。

待办事项我想引用一些参考，但是我也希望缺少参考不会妨碍我共享信息的能力，因此我将快速引用我记得的信息我的信息，也许有一天我会找到实际信息（或者您可以为我找到！）
一位GitHub员工表示，他们避免在Y-Combinator上雇用聪明的人
Python社区中进行的许多讨论和学习。 Python社区特别批评新想法，但是并不会忽略他们无法理解的新想法，并且通常可以将最初被认为是令人费解的功能看作是核心语言功能/包。
基于我的10000英尺观察，我自己的经验和专业意见。我从那里一直都看不到有什么启发性的细节：（（希望您的经验和观察会告诉您同样的事情，并且其他人可以在下面发表评论以给出一些答案。 >随时添加您自己的引文！另外，请随时在文本中添加逗号。很长一段时间我都没有刷新关于英文逗号用法的知识...

#27 楼

因为人们常常不懂某种语言，习语和模式。他们可以拿一本书来学习，但事实并非如此。由于这些人，您应该编写简单的代码。

这不是一个聪明的做法。这是一种知识。

#28 楼

我在这里附近找不到“学科”一词，因此我将继续讨论。我不想发布答案，但想就此问题分享不同的见解，也许是原始问题没有想到的问题。

一个聪明的开发者是一件好事。

但是，在聪明才出现其他特征之前。您可能已经意识到，我将谈论纪律。聪明而不受纪律的开发人员可能对系统的长期可维护性非常不利。

假设出现了错误或提出了新的要求。聪明的开发人员可能会很快意识到几个本地修复程序会在2分钟内完成工作。如果该开发人员受到纪律处分，他将阻止将这些修订应用于源代码，而是将找到一种有意义的方式来将所需的行为组合到系统中。这样，下次需要修改特定代码段时，维护人员将有一个轻松的时间来理解代码并实现新的更改而不会破坏任何内容。如果没有，那么您就知道了。