这绝对是主观的，但我想尽量避免它变得有争议。我认为，如果人们能恰当地对待它，这可能是一个有趣的问题。

这个问题的想法来自我对"你最喜欢的语言有五件事你讨厌吗？"的回答的评论线索。问题。我主张C中的课程应该默认密封——我不会把我的推理放在问题中，但我可能会写一个更完整的解释来回答这个问题。我对评论中讨论的热度感到惊讶(目前有25条评论)。

那么，你有什么有争议的意见？我宁愿避免这样的事情，结果是相当宗教，相对较少的基础(如支撑放置)，但例子可能包括"单元测试实际上没有太大的帮助"或"公共领域真的很好"。重要的是(对我来说，不管怎样)，你的观点背后有理由。

请陈述你的观点和推理——我鼓励人们投票赞成那些有充分理由和有趣的观点，不管你是否同意它们。

不在业余时间编写代码以取乐的程序员永远不会像那些程序员那样优秀。

我认为即使是最聪明和最有才华的人也永远不会成为真正优秀的程序员，除非他们把它当作工作来对待。也就是说，他们一边做一些小项目，或者只是在业余时间处理大量不同的语言和想法。

(注：我不是说优秀的程序员只做编程，但他们只做从9到5的程序)

你应该一直使用的唯一"最佳实践"就是"用你的大脑"。

太多的人跳上太多的乐队，试图把方法、模式、框架等强加于不值得他们去做的事情上。仅仅因为某件事是新的，或者因为某个受人尊敬的人有一个观点，并不意味着它适合所有人。

编辑：只是为了澄清——我认为人们不应该忽视最佳实践、有价值的观点等。只是人们不应该只是盲目地跳上某个东西，而不去想为什么这个"东西"如此伟大，它是否适用于我正在做的事情，它带来了什么好处/缺点？

"谷歌"没关系！

是的，我知道这冒犯了一些人，因为他们多年来的紧张记忆和/或精彩的编程书籍开始从一个任何人都可以在几秒钟内访问的资源的路旁跌落，但你不应该对使用它的人持这种态度。

我经常听到谷歌搜索问题的答案——批评的结果，这真的是毫无意义。首先，必须承认，每个人都需要参考资料。你不知道所有的事情，你需要去查查。尽管如此，你从哪里得到信息真的很重要吗？如果你在书中查到它，在谷歌上查到它，或者从一只会说话的青蛙那里听到你产生幻觉，这有关系吗？不，正确的答案就是正确的答案。

重要的是，你要理解材料，把它作为结束成功编程解决方案的手段，客户/你的雇主对结果很满意。

(尽管如果你从会说梦话的青蛙那里得到答案，你还是应该得到一些帮助)

实际上，代码中的大多数注释都是有害的代码复制形式。

我们大部分时间都在维护他人(或我们自己)编写的代码，而糟糕的、不正确的、过时的、误导性的注释必须位于代码中最令人讨厌的工件列表的顶部。

我想，最终很多人都会把它们抹掉，尤其是那些花坛怪兽。

更好的做法是集中精力使代码可读，必要时进行重构，尽量减少惯用语和怪癖。

另一方面，许多课程告诉我们，注释比代码本身更重要，因此下一行将添加一个到invoicetotal注释样式中。

XML被高估了

我认为在使用他们的大脑之前，有太多人跳上了XML的潮流…XML for Web东西很好，因为它是为它设计的。否则，我认为一些问题定义和设计思想应该优先于使用它的任何决定。

我的5分钱

并非所有的程序员都是平等的

通常，管理者认为developera==developerb仅仅是因为他们具有相同的经验水平等等。实际上，一个开发人员的性能可以是另一个开发人员的10倍甚至100倍。

谈论这件事在政治上是有风险的，但有时我想指出的是，即使几个团队成员看起来技能相同，但情况并非总是如此。我甚至看到过这样的情况：主要开发人员"无望"，初级开发人员完成了所有实际工作——不过，我确保他们获得了荣誉。：)

我不明白为什么人们认为Java绝对是大学里最好的"第一"编程语言。

首先，我认为第一种编程语言应该强调学习控制流和变量的需要，而不是对象和语法。

另一方面，我相信那些在C/C++中没有调试内存泄漏经验的人不能完全理解Java带来了什么。

另外，自然的进展应该是从"我怎么能做到这一点"到"我怎么能找到这样做的图书馆"，而不是反过来。

如果你只知道一种语言，不管你多么了解它，你都不是一个伟大的程序员。

似乎有一种态度说一旦你真的擅长C语言或Java或者你开始学习的任何其他语言，那就是你所需要的。我不相信——我所学的每一种语言都教会了我一些编程方面的新知识，我已经能够把它们带回到我的工作中去。我认为任何一个限制自己使用一种语言的人永远不会像他们那样优秀。

对我来说，它也表明了我缺乏某种求知欲和尝试的意愿，这并不一定符合我期望在一个真正优秀的程序员身上找到的品质。

性能确实很重要。

print语句是调试代码的有效方法

我认为，通过将代码与System.out.println或任何适用于您的语言的print语句混合使用来调试代码是非常好的。通常，这比调试更快，并且您可以将打印输出与应用程序的其他运行进行比较。

在进入生产阶段时，只需确保删除打印语句(或者更好地，将其转换为日志语句)。

你的工作就是让自己失业。

当你为你的雇主编写软件时，你所创建的任何软件都要以这样一种方式来编写，即任何开发人员都可以用最少的努力来获取和理解它。它设计良好，书写清晰一致，格式清晰，在需要的地方有文档记录，按预期每天构建，检入到存储库中，并进行适当的版本控制。

如果你被公共汽车撞了，被解雇，被解雇，或者辞职，你的雇主应该能够在一瞬间通知你，然后下一个家伙可以进入你的岗位，拿起你的代码，在一周内开始工作。如果他或她不能做到，那你就惨败了。

有趣的是，我发现有了这个目标，我对我的雇主更有价值。我越努力做到一次性，我对他们就越有价值。

1)商业应用程序闹剧：

我认为整个"企业"框架就是烟雾和镜子。j2ee，.net，大多数Apache框架和管理这些东西的大多数抽象产生了比它们解决的复杂得多的复杂性。

使用任何规则的Java或.NET ORM，或者任何假设的现代MVC框架，为那些"魔术"来解决繁琐、简单的任务。最后会编写大量难看的XML样板文件，这些文件很难验证和快速编写。你有大量的API，其中的一半只是集成其他API的工作，不可能回收的接口，以及抽象的类，只需要克服Java和C的不灵活。我们根本不需要这些。

所有不同的应用服务器都有自己的darned描述符语法，过于复杂的数据库和群件产品呢？

这并不是说复杂性==坏，而是说不必要的复杂性==坏。我曾在大型企业安装中工作过，其中一些是必要的，但即使在大多数情况下，解决大多数用例也只需要一些自行开发的脚本和简单的Web前端。

我将尝试用简单的Web框架、开放源代码DBS和简单的编程结构替换所有这些企业应用程序。

2)所需n年经验：

除非您需要顾问或技术人员来处理与应用程序、API或框架相关的特定问题，否则您实际上不需要具有5年应用程序经验的人员。你需要的是一个能够阅读文档的开发人员/管理员，他对你正在做的任何事情都有领域知识，并且能够快速学习。如果你需要用某种语言进行开发，一个优秀的开发人员将在不到2个月的时间内完成。如果您需要X Web服务器的管理员，他应该在两天内读完手册页和新闻组，并跟上进度。再少一点，那人就不值得他付出什么。

3)普通"计算机科学"学位课程：

大多数计算机科学和软件工程学位都是牛市。如果你的第一个编程语言是Java或者C语言，那么你就做错事了。如果你没有上好几门代数和数学的课程，那就错了。如果你不深入研究函数式编程，它是不完整的。如果你不能将循环不变量应用到一个微不足道的for循环中，作为一个假定的计算机科学家，你就不值得你的盐了。如果你在X和Y语言和面向对象方面都有经验，那就充满了S*。一个真正的计算机科学家从一种语言所使用的概念和句法的角度来看待它，把编程方法看作是众多方法中的一种，并且对这两种方法的基本原理有着很好的理解，因此选择新的语言、设计方法或规范语言应该是微不足道的。

吸气剂和二传手使用过度

我见过数以百万计的人声称公共领域是邪恶的，所以他们将其私有化，并为所有人提供获取者和设置者。我相信这与公开字段几乎是相同的，如果您使用线程(但通常不是这样)，或者如果您的访问器具有业务/表示逻辑(至少是"奇怪的")，可能会有点不同。

我不赞成公共字段，而是反对为每个字段创建getter/setter(或属性)，然后声称这样做是封装或信息隐藏…哈！

更新：

这个答案在它的评论中引起了一些争议，所以我会尽量澄清一下(我会保持原样不变，因为这是很多人反对的)。

首先：任何使用公共领域的人都应该坐牢

现在，创建私有字段，然后使用IDE为每一个字段自动生成getter和setter几乎和使用公共字段一样糟糕。

很多人认为：

private fields + public accessors == encapsulation

我说(自动或不自动)为您的字段生成getter/setter对有效地违背了您试图实现的所谓封装。

最后，让我引用鲍勃叔叔的话(摘自《清洁代码》第6章)：

There is a reason that we keep our
variables private. We don't want
anyone else to depend on them. We want
the freedom to change their type or
implementation on a whim or an
impulse. Why, then, do so many
programmers automatically add getters
and setters to their objects, exposing
their private fields as if they were
public?

UML图被高估了

当然，有一些有用的图，例如复合模式的类图，但是许多UML图绝对没有价值。

意见：SQL是代码。像这样对待它

也就是说，就像你的C语言、Java或其他喜欢的对象/过程语言一样，开发一种可读和可维护的格式化风格。

我讨厌看到随意格式化的SQL代码。如果在一个页面上看到两种样式的花括号时都尖叫，那么当看到隐藏或模糊连接条件的自由格式SQL或SQL时，为什么不尖叫呢？

可读性是代码最重要的方面。

比正确性更重要。如果它可读，很容易修复。它也易于优化，易于更改，易于理解。希望其他开发人员也能从中学习到一些东西。

如果您是开发人员，您应该能够编写代码

去年我做了很多面试，在我的面试中，我要测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我最初的问题是：

Given that Pi can be estimated using the function 4 * (1 - 1/3 + 1/5 - 1/7 + ...) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

这是一个应该让你思考的问题，但是对于一个经验丰富的开发人员来说不应该是遥不可及的(它可以用大约10行C来回答)。然而，我们的许多候选人(据说是由该机构预先筛选的)甚至无法回答，甚至无法解释他们如何回答。所以过了一会儿，我开始问一些简单的问题，比如：

Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.

令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数(我可以阅读最流行的语言，所以我让他们使用他们选择的任何语言，包括伪代码)。我们有"c开发人员"，他们不能用c编写这个函数。

我对此感到惊讶。我一直认为开发人员应该能够编写代码。现在看来，这是一个有争议的观点。当然是面试中的候选人！

编辑：

关于第一个问题是好问题还是坏问题，以及你是否应该在面试中提出如此复杂的问题，评论中有很多讨论。我不会在这里深入探讨这个问题(这是一个全新的问题)，除了说你基本上错过了帖子的要点。

是的，我说过人们不能在这方面取得任何进展，但第二个问题是微不足道的，许多人也不能在这方面取得任何进展！任何自称为开发人员的人都应该能够在几秒钟内写出第二个问题的答案，而不必思考。很多人不能。

使用匈牙利符号应处以死刑。

这应该引起足够的争议；)

设计模式对好的设计所造成的伤害远大于它们对它的帮助。

IMO软件设计，尤其是优秀的软件设计，太过多样化，无法有意义地捕捉到模式，尤其是在人们实际能记住的少量模式中——而且这些模式太抽象，人们无法真正记住太多的模式。所以他们没什么帮助。

另一方面，太多的人沉迷于这个概念，并尝试在任何地方应用模式——通常，在生成的代码中，您无法在所有(完全没有意义的)单例工厂和抽象工厂之间找到实际的设计。

代码越少越好！

如果用户说"就这样？"你的工作还是看不见的，做得对。荣耀可以在别处找到。

PHP吸吮；

证据在布丁里。

单元测试不能帮助您编写好的代码

进行单元测试的唯一原因是确保已经运行的代码不会中断。首先编写测试，或者向测试中编写代码是荒谬的。如果在代码之前编写测试，您甚至不知道边缘情况是什么。您可以拥有通过测试但在不可预见的情况下仍然失败的代码。

而且，优秀的开发人员将保持低内聚性，这将使得添加新代码不太可能导致现有代码出现问题。

实际上，我会更进一步地概括这一点，

软件工程中的大多数"最佳实践"都是为了防止坏的程序员造成过多的损害。

他们会抓住不好的开发人员，防止他们犯愚蠢的错误。当然，由于大多数开发人员都很差劲，这是一件好事，但优秀的开发人员应该得到一个通行证。

写一些小方法。程序员似乎喜欢编写looong方法，在那里他们可以做多种不同的事情。

我认为应该在任何可以命名的地方创建一个方法。

偶尔写一次垃圾代码没关系

有时，为了完成特定的任务，只需要一段快速而脏的垃圾代码。模式，窗体，SRP，无论什么…抛出一个控制台或Web应用程序，编写一些内联SQL(感觉很好)，然后爆发出需求。

代码=设计

我不喜欢复杂的UML图和无休止的代码文档。在高级语言中，您的代码应该是可读的和可以理解的。复杂的文档和图表实际上不再是用户友好的了。

这是一篇关于代码即设计的文章。

软件开发只是一项工作

别误会，我很喜欢软件开发。最近几年我写了一篇关于这个问题的博客。我在这里花了足够的时间获得超过5000点的声誉。我在一家初创公司工作，每周工作60个小时，所花的钱比我作为一个承包商所能得到的要少得多，因为团队很棒，工作也很有趣。

但在宏伟的计划中，这只是一份工作。

它的重要性低于许多事情，如家庭、我的女朋友、朋友、幸福等，也低于其他我宁愿做的事情，如果我有无限的现金供应，如骑摩托车、帆船或滑雪板。

我认为有时候很多开发人员忘记了开发只是让我们在生活中拥有更重要的东西(并且通过做我们喜欢的事情来拥有它们)，而不是成为最终目标本身。

我还认为在源代码管理中使用二进制文件没有什么问题。如果有充分的理由的话。如果我有一个程序集，我没有它的源，并且可能不一定在每个devs机器上的同一个位置，那么我通常将它粘贴在"二进制文件"目录中，并使用相对路径在项目中引用它。

相当多的人似乎认为我在同一句话中提到"源代码控制"和"二进制"都应该受到惩罚。我甚至知道有一些地方有严格的规定说你不能添加它们。

每个开发人员都应该熟悉现代计算机的基本体系结构。这也适用于以虚拟机为目标的开发人员(可能更严重，因为他们一次又一次地被告知他们不需要担心内存管理等问题)。

软件架构师/设计师被高估了

作为开发人员，我讨厌软件架构师的想法。他们基本上不再是全职编码，阅读杂志和文章，然后告诉你如何设计软件的人。只有那些真正以写软件为生的人才应该这样做。我不管你是不是5年前成为建筑师前世界上最好的程序员，你的观点对我来说毫无用处。

有争议怎么办？

编辑(澄清)：我认为大多数软件架构师都是优秀的业务分析师(与客户交谈、编写需求、测试等)，我只是认为他们在设计软件、高层或其他方面没有位置。

没有"一刀切"的发展方法

我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在流行的博客上有很多条目提倡"一刀切"的发展方式，所以我认为我可能实际上是少数。

我所看到的被吹捧为任何项目的正确方法的东西——在任何关于它的信息被了解之前——是诸如测试驱动开发(TDD)、域驱动设计(DDD)、对象关系映射(ORM)、敏捷(Capital A)、对象定向(OO)等的使用，包括从方法论到体系结构的所有东西。O组件。当然，所有这些词都有很好的首字母缩写。

人们甚至在自己的博客上贴上徽章，比如"我是测试驱动的"或者类似的东西，就好像他们严格坚持一种单一的方法，不管项目的细节实际上是一件好事。

不是这样。

选择正确的方法、体系结构和组件等，不仅取决于您所从事的项目的类型及其独特的需求，还取决于您所从事的团队的规模和能力。

大多数专业程序员都很差劲

我遇到过太多为生计而做这项工作的人，他们对自己所做的工作简直是一无是处。糟糕的代码，糟糕的沟通技巧，对新技术毫无兴趣。太多，太多…

计算机科学学位并不能——也不应该——教你做程序员。

编程是一门贸易，计算机科学是一门研究领域。你可以是一个伟大的程序员，一个可怜的计算机科学家，一个伟大的计算机科学家和一个糟糕的程序员。理解两者的区别是很重要的。

如果你想成为程序员，学习Java。如果你想成为一名计算机科学家，至少要学习三种几乎完全不同的语言。例如(汇编程序、C、lisp、ruby、smalltalk)

SESE(单入口单出口)不是法律

例子：

VS：

我和我的团队发现，在许多情况下，一直遵守这一点实际上会适得其反。

C++是有史以来最糟糕的编程语言之一。

它具有委员会设计的所有特征——它不能很好地完成任何给定的工作，而且做一些工作(如OO)非常糟糕。它有一个"厨房水槽"绝望，只是不会消失。

学习编程是一门可怕的"第一语言"。你得不到优雅，也得不到帮助(语言)。相反，您有bear陷阱和mine字段(内存管理、模板等)。

尝试学习OO概念不是一种好的语言。它的行为是"带有类包装器的C"，而不是正确的OO语言。

我可以继续说下去，但暂时不谈了。我从未喜欢C++编程，虽然我在FORTRAN上"咬牙切齿"，但我完全喜欢C语言的编程。我仍然认为C是伟大的"经典"语言之一。在我看来，C++当然不是。

干杯，

-R

编辑：响应对C++教学的评论。你可以用两种方式教C++——教给它"类固醇上的C"(从变量、条件、循环等)开始，或者教它作为一种纯粹的"OO"语言(从类、方法等开始)。您可以找到使用这些方法中的一种或其他方法的教学文本。我更喜欢后一种方法(OO第一)，因为它强调C++作为一种面向对象语言的能力(这是C++的最初设计重点)。如果你想教C++"C"，那么我认为你应该教C，而不是C++。

但是在我的经验中，C++作为第一语言的问题是，语言在一个学期里太大以至于不能教，而且大多数的"介绍"文本都试图覆盖一切。在"第一语言"课程中不可能涵盖所有的主题。你至少要把它分成两个学期，然后它就不再是"第一语言"，我的意思是。

我教C++，但只是作为一种"新的语言"——也就是说，你必须精通一些以前的"纯"语言(不是脚本或宏)，然后才可以参加课程。C++是一种很好的"第二语言"，IMO.

-R

'其他编辑：(给康拉德)

我根本不同意C++在各个方面都是优越的。C。我花了多年的时间编写C程序，用于微控制器和其他嵌入式应用程序。这些设备的C编译器是高度优化的，通常产生的代码和手工编码的汇编程序一样好。当你移动到C++时，编译器会给你带来巨大的开销，以便管理你可能不使用的语言特性。在嵌入式应用程序中，通过添加类之类的东西(imo)几乎没有什么好处。您需要的是紧凑、干净的代码。你可以用C++编写它，但是你真的只是在写C，C编译器在这些应用程序中被优化了。

我写了一个MIDI引擎，首先在C，后来在C++(在供应商的请求下)为嵌入式控制器(声卡)。最后，为了满足性能需求(MIDI计时等)，我们必须将所有核心代码恢复为纯C。我们能够使用C++来实现高级代码，并且具有非常好的类，但是我们需要C来获得较低级别的性能。C代码比C代码快了一个数量级，但是手工编码的汇编程序只比编译的C代码稍微快一点。这要追溯到20世纪90年代初，只是为了恰当地安排事件。

-R

你必须知道如何打字才能成为一名程序员。

这在那些不知道如何打字的人中是有争议的，但是他们坚持说他们能像任何打字员一样快速地进行两个手指的搜寻和啄食，或者他们不需要花那么多时间打字，或者智能感知减轻了打字的需要……

我从来没有见过会打字的人，但我坚持认为这没什么区别。

另见：编程最肮脏的小秘密

懒惰的程序员是最好的程序员

懒惰的程序员通常会找到减少编写代码所花费时间的方法(尤其是大量相似或重复的代码)。这通常转化为公司/团队中的其他开发人员可以从中受益的工具和工作流。

当开发人员遇到类似的项目时，他可能会创建工具来引导开发过程(例如，创建一个与公司的数据库设计范例一起工作的DRM层)。

此外，这些开发人员通常使用某种形式的代码生成。这意味着同一类型的所有错误(例如，代码生成器没有检查所有方法上的空参数)通常可以通过修复生成器而不是修复该错误的50多个实例来修复。

一个懒惰的程序员可能需要几个小时才能把第一个产品带出门，但这样可以节省你几个月的时间。

计算机科学或其他IT领域的学位确实使你成为一个更全面的程序员。

我不在乎你有多少年的经验，你读过多少博客，你参与了多少开源项目。一个资格(我建议超过3年)暴露给你一种不同的思维方式，给你一个伟大的基础。

仅仅因为你写的代码比一个拥有计算机科学学士学位的人好，并不意味着你比他好。你所拥有的，他可以在一瞬间得到，但事实并非如此。

拥有一个资格证明了你的承诺，事实上你将超越经验，使你成为一个更好的开发人员。开发人员擅长他们所做的工作，并且有资格，这可能是非常可怕的。

如果这个答案被否决，我不会感到惊讶。

而且，一旦你有了资格，你就慢慢地停止把自己和那些有资格的人(我的经验)比较。你知道，只要你能很好地合作，最后一切都无关紧要。

无论资质如何，始终对其他开发人员仁慈行事。

不要使用继承，除非你能解释为什么你需要它。

世界需要更多的哥特人

"我的教授告诉我，Gotos是坏的"，Gotos经常被虔诚地避免，而且没有任何理由，它们有一个目的，在许多地方都会大大简化生产代码。

也就是说，99%的代码都不需要它们。

我以前因为在公共场合发表这些意见而被烧死，但现在我要说的是：

动态类型语言中编写良好的代码遵循静态类型约定

使用了python、php、perl和其他一些动态类型语言之后，我发现这些语言中编写良好的代码遵循静态类型约定，例如：

• 重新使用具有不同类型的变量(例如，它的错误样式是获取一个列表变量并分配一个int，然后在同一方法中为变量分配一个bool)。用动态类型语言编写良好的代码不会混合类型。

• 静态类型语言中的类型错误仍然是动态类型语言中的类型错误。

• 函数通常设计为一次在单个数据类型上操作，因此接受T类型参数的函数只能明智地与T类型的对象或T的子类一起使用。

• 为许多不同数据类型上的运算符设计的函数以一种将参数约束到定义良好的接口的方式编写。一般来说，如果两个类型为A和B的对象执行类似的功能，但不是彼此的子类，那么它们几乎肯定实现了相同的接口。

虽然动态类型化语言当然提供了不止一种方法来破解一个难题，但这些语言中最优秀的、惯用的代码与用静态类型化语言编写的代码一样严格地关注类型。

动态类型不能减少程序员需要编写的代码量

当我指出有如此多的静态类型约定跨越到动态类型世界是多么的奇怪时，我通常会加上一句："那么为什么要使用动态类型语言来开始呢？".即时响应是指能够编写更简洁、更具表现力的代码，因为动态类型允许程序员省略类型注释和显式定义的接口。但是，我认为最流行的静态类型语言，例如C语言、Java和Delphi，由于设计而庞大，而不是它们的类型系统的结果。

我喜欢使用带有真正类型系统(如ocaml)的语言，它不仅是静态类型的，而且它的类型推断和结构类型允许程序员省略大多数类型注释和接口定义。

ML语言家族的存在证明了我们可以享受静态类型的好处，同时动态类型语言中的写作也非常简洁。实际上，我使用ocaml的repl来处理临时的、一次性的脚本，与其他人使用Perl或Python作为脚本语言的方式完全相同。

花一整天时间回答StackOverflow问题的程序员可能没有完成他们要支付的工作。

代码布局很重要

也许大括号位置的细节应该保持纯粹的宗教争论——但这并不意味着所有的布局样式都是相同的，或者根本没有客观因素！

问题是，布局的优步规则，也就是说："保持一致"，听起来像是，被许多人用作拐杖，从不试图看他们的默认样式是否可以改进——而且，这甚至都无关紧要。

几年前，我在学习快速阅读技术，我学到了一些关于眼睛如何在"注视"中接收信息的知识，可以最理想地扫描页面，以及下意识地获取上下文的作用，这些知识让我想到了这是如何应用于代码的，尤其是在编写代码时。

它使我形成了一种本质上倾向于列式的风格，在可能的情况下，标识符在逻辑上分组并对齐(特别是，我对每个方法参数都有自己的行变得严格)。然而，与长列不变的结构相比，将结构分块改变实际上是有益的，这样你最终会得到矩形的孤岛，眼睛可以在一个固定装置中接受，即使你没有意识到阅读每个角色。

最终的结果是，一旦你习惯了它(通常需要1-3天)，它就变得让眼睛高兴，更容易理解，也更快理解，而且对眼睛和大脑的负担也更少，因为它的布局方式使它更容易接受。

几乎没有例外，我要求尝试这种风格的每个人(包括我自己)最初都说，"啊，我讨厌它！"但一两天后，我说："我爱它——我发现很难不回去，用这种方式重写我所有的旧东西！".

我一直希望有时间做更多的控制性实验，收集足够的证据，写一篇论文，但和以往一样，我忙于其他事情。然而，这似乎是一个向对有争议的技术感兴趣的人提起它的好机会。

[编辑]

我终于开始写博客了(在"意义到"阶段停留了很多年之后)：第一部分，第二部分，第三部分。

意见：显式变量声明是一件大事。

我永远不会理解让开发人员浪费大量时间跟踪由变量名拼写错误引起的运行时错误的"智慧"，而不仅仅是让编译器/解释器捕获这些错误。

没有人能比"我不用写‘int i；’"更能给我一个解释了。是的，当然，但跟踪运行时错误需要多长时间？

意见：在"调试"和"发布"构建之间永远不会有不同的代码

主要原因是发布代码几乎从未经过测试。最好在测试中运行与野外运行相同的代码。

意见：开发人员应该测试自己的代码

我看到过太多的垃圾被交给了测试，结果它并没有真正修复问题中的bug，导致了通信开销和培养不负责任的实践。

分页永远不是用户想要的

如果您开始讨论在数据库、业务逻辑、客户机等中在何处进行分页，那么您提出的问题是错误的。如果你的应用程序返回的数据比用户需要的多，那么你可以找到一种方法，让用户根据实际的标准而不是任意大小的块来缩小他们需要的数据。如果用户真的想要所有这些结果，那么就给他们所有的结果。你一次给谁20块钱？服务器？这比你的用户更重要吗？

[编辑：澄清，基于评论]

作为一个现实世界的例子，让我们看看这个堆栈溢出问题。假设我有一个有争议的编程意见。在我发帖之前，我想看看是否已经有一个答案可以解决相同的意见，所以我可以投反对票。我唯一的选择就是点击每一页答案。

我更喜欢以下选项之一：

如果我只是想找到我以前读过的答案，但现在找不到了，这同样适用。我不知道它是什么时候发布的，也不知道它有多少选票，所以排序选项没有帮助。即使我这样做了，我还是要玩猜谜游戏才能找到正确的结果页面。答案是分页的，我可以直接点击十几页中的一页，这一点毫无帮助。

——骨形态发生蛋白B

尊重单一责任原则

乍一看，你可能并不认为这会引起争议，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做任何事情时，他们常常会推回……所以对于孩子们来说，请不要再建立我们经常看到的"做每件事"的方法。

不编码的架构师是无用的。

听起来有点刺耳，但这并不不合理。如果您是一个系统的"架构师"，但是对所使用的技术没有实际的参与，那么您如何获得开发团队的尊重呢？你如何影响方向？

架构师需要做更多的工作(与利益相关者会面、与其他团队谈判、评估供应商、编写文档、提供演示文稿等)，但是，如果您从未看到架构师签入的代码……小心！

对象不应处于无效状态

不幸的是，许多ORM框架要求所有实体类都使用零arg构造函数，使用setter填充成员变量。在这些情况下，很难知道必须调用哪些setter才能构造有效的对象。

在我看来，对象不可能发现自己处于无效状态，并且类的API应该在每次方法调用后主动强制其类不变量。

构造函数和赋值函数方法应该原子地将对象从一个有效状态转换到另一个有效状态。这更好：

作为某些库的使用者，在试图使用对象之前跟踪是否调用了所有正确的setter是件很麻烦的事情，因为文档通常不提供有关类合同的线索。

源代码管理：除了SourceSafe以外的任何内容

另外：专用锁是邪恶的。

我曾经在某个地方工作过，在那里他们认为独占锁意味着当您签入时，您保证人们不会覆盖其他人的更改。问题是，为了完成任何工作，如果一个文件被锁定，devs只需将其本地文件更改为可写，并在有机会时将源代码管理与其版本合并(或覆盖)。

默认情况下，所有变量/属性都应为readonly/final。

这种推理有点类似于乔恩提出的关于类的sealed论证。程序中的一个实体应该有一个作业，并且只有一个作业。尤其是，对于大多数变量和属性来说，改变值绝对没有意义。基本上有两个例外。

我意识到今天的大多数语言并不是为了默许我的愿望而建立的。在我看来，所有这些语言都有根本的缺陷。如果将它们更改为默认情况下将所有变量视为只读，并且在初始化之后不允许对它们进行任何分配，那么它们将不会失去任何表现力、能力和易用性。

意见：单元测试不需要预先编写，有时根本不需要。

理由：开发人员在测试自己的代码方面很差劲。是的。这就是为什么我们通常有测试团队或质量保证小组。

大多数时候，我们编写的代码是与要单独测试的其他代码交织在一起的，所以我们最终跳过了模式化的环来提供可测试性。并不是说那些模式是坏的，但它们有时会增加不必要的复杂性，所有这些都是为了单元测试…

…这通常都不起作用。编写一个全面的单元测试需要大量的时间。往往比我们愿意付出的时间更多。测试越全面，如果它测试的对象的接口发生变化，它就越容易变得脆弱，从而强制重写不再编译的测试。

认识到有时候足够好就足够好了，这是作为一个程序员你的价值的一次重大飞跃。

注意，当我说"足够好"的时候，我的意思是"足够好"，但这并不是什么废话。但是，当你在时间紧迫的时候，"一些恰巧有用的垃圾"可能被认为是"足够好的"。

如果我有争议的话，我得建议乔恩·斯基特不是万能的。

"爪哇吮吸"-是的，我知道意见绝对不是所有人持有的：

我有这样的观点，因为我见过的大多数Java应用程序都是内存堆，运行速度慢，用户界面非常糟糕等等。

G-man

好吧，我说我会更详细地谈谈我的"封闭课程"意见。我想有一种方法可以显示出我感兴趣的答案，那就是我自己给出一个答案。

意见：类应在C中默认密封#

推理：

毫无疑问，遗产是强大的。然而，它必须有所指导。如果有人以完全出乎意料的方式从基类派生，这可能会破坏基本实现中的假设。考虑基类中的两个方法，其中一个调用另一个方法-如果这些方法都是虚拟的，那么必须记录实现细节，否则，有人可能相当合理地重写第二个方法，并期望对第一个方法的调用能够工作。当然，一旦实现被记录在案，它就不能被改变…所以你失去了灵活性。

C通过对默认方法进行密封，朝着正确的方向(相对于Java)迈出了一步。然而，我相信，进一步的步骤——让类在默认情况下被密封——会更好。特别是，很容易重写方法(或者不显式地密封不重写的现有虚拟方法)，从而导致意外的行为。这并不能阻止你做任何你现在能做的事情——它只是改变一个默认值，而不是改变可用的选项。不过，这将是一个"更安全"的默认值，就像C中的默认访问始终是"当时可用的最私有的可见性"。

通过让人们明确地说他们希望人们能够从他们的课程中获得灵感，我们会鼓励他们更多地思考这个问题。这也会帮助我解决懒惰的问题——虽然我知道我应该封闭几乎所有的课程，但实际上我很少记得这样做：(

反参数：

我可以看到这样一个论点：没有虚拟方法的类可以相对安全地派生出来，而不需要额外的不灵活性和通常需要的文档。我不知道现在该如何对付这个问题，除了说我相信意外打开类的伤害要比意外关闭类的伤害大。

聪明的程序员是危险的。

我花了更多的时间试图修复"聪明"程序员编写的代码。我宁愿有一个好的程序员，也不愿有一个非常聪明的程序员，他想通过编写只有他(或她)才能解释的代码来证明自己有多聪明。

糟糕的程序员是语言不可知论者

一个非常糟糕的程序员几乎可以用任何语言编写糟糕的代码。

避免缩进。

使用提前归还、继续或休息。

而不是：

做：

如果您知道如何编程，则不适合在窗体上放置按钮

这有足够的争议吗？；)

无论我们多么努力，都几乎不可能与不得不使用我们的订单输入软件的53岁的Doris产生适当的共鸣。我们根本无法理解她想象的在电脑里发生的事情的心理模型，因为我们不需要想象：我们知道发生了什么，或者有一个非常好的主意。

交互设计应该由非程序员完成。当然，这永远不会发生。矛盾的是，我很高兴这一点；我喜欢UI设计，尽管内心深处我知道我不适合它。

欲知更多信息，请阅读《囚犯经营庇护所》一书。请注意，我发现这本书令人沮丧和侮辱；如果你是一个关心用户体验的开发人员，那么阅读起来很困难。

在1970年1月1日之前，对与错是相反的…

我可能会为此被烤，但是：

让不可见的字符在python中具有语法意义是个坏主意

它让人分心，给新手带来很多微妙的错误，在我看来，这并不是真正需要的。我见过的唯一一个没有自愿遵循某种像样格式指南的代码是来自一年级的CS学生。即使代码不遵循"好"的标准，也有很多工具可以将其强制为更令人满意的形状。

应从OO语言中删除空引用

来自Java和C语言背景，在正常情况下，从一个方法返回null来指示一个失败，我得出结论，空值会导致很多可避免的问题。如果只从代码中消除空引用，语言设计器可以删除与nullreferenceexceptions相关的整类错误。

另外，当我调用一个方法时，我无法知道该方法是否可以返回空引用，除非我在实现中进行了深入研究。我希望看到更多的语言遵循F处理空值的模型：F不允许程序员返回空引用(至少对于用F编译的类)，而是要求程序员使用option类型表示空对象。这种设计的好处在于，函数是否可以返回空引用等有用信息如何通过类型系统传播：返回类型'a的函数的返回类型与返回类型'a option的函数的返回类型不同。

你不必为每件事都编程序

我对每件事都感到厌倦了，但是每件事都需要被塞进一个程序中，就像这样总是更快。一切都需要网络化，任何事情都需要通过计算机来完成。请用你的笔和纸。它速度更快，维护更少。

如果你不知道就好了。但如果你连谷歌都不能搜索，你就被解雇了。

互联网是一种工具。如果你从中吸取教训，这不会让你变得更傻。

单身不是坏事

在现实世界中有一个单身汉的地方，而绕过他们的方法(即单态模式)只是伪装成单身汉。例如，一个记录器是一个单例的完美候选对象。另外，信息泵也是如此。我当前的应用程序使用分布式计算，不同的对象需要能够发送适当的消息。应该只有一个消息泵，每个人都可以访问它。另一种选择是将一个对象传递到可能需要的任何地方，并希望一个新的开发人员在不经过思考和思考的情况下不会有新的开发人员。单例的唯一性是最重要的部分，而不是它的可用性。单身汉在世界上占有一席之地。

一幅画不值得千言万语。

有些照片可能值一千字。他们中的大多数不是。这句陈词滥调的格言大多是不真实的，对于许多懒惰的经理来说，这是一个可悲的借口，他们不想仔细阅读创建的报告和文档，说"我需要你给我一个图表。"

我妻子学的是语言学专业，她看到了一些与传统的图片和标识智慧相反的有趣证据：它们不会突破语言和文化障碍，它们通常不会在任何地方交流到与正确的文本一样多的信息，它们只是无法替代真实的交流。

尤其是，如果线条未标记和无法解释，和/或每一线条都有不同的含义，而不是表示相同的关系(除非以某种方式彼此区分)，则与线条相连的标记气泡是无用的。如果你的台词有时意味着关系，有时意味着行动，有时意味着时间的流逝，那么你真的很受欢迎。

每一个优秀的程序员都知道你使用的是适合手头工作的工具，对吧？并非所有的系统都是最好的指定和记录在图片中。图形规范语言，可以自动转换成可证明是正确的、可执行的代码，或者是一个壮观的想法(如果存在的话)。在适当的时候使用它们，而不是在阳光下使用。实体关系图很棒。但并不是每件事都能概括成一幅图画。

注意：一张桌子可能值它的黄金重量。但是一张桌子和一张照片不一样。再者，一段精雕细琢的短文可能更适合手头的工作。

正如一位聪明的老师曾经告诉我的："不要写代码，写代码是坏的，删除代码是好的。如果你必须写代码-写小代码…"

你需要注意那些痴迷于对象的程序员。

例如，如果您编写一个类来为内置类型(如int或float)建模，那么您可能是一个痴迷于对象的程序员。

外面有很多糟糕的教学。

当乔尔说大脑中有一部分是用来理解一些人天生就没有的指针时，我们的开发人员会感到非常优越。我们中的许多人在这里讨论的话题都是深奥的，但有时这只是因为我们让它们如此。

在开发代码时，最好记住优化。

每当我这样说，人们总是回答："过早的乐观是万恶之源"。

但在调试之前我不是说优化。我甚至从来没有说过"优化"，但是在设计代码时，请记住这可能成为一个瓶颈，并编写它，这样就可以快速地重构代码，而不会将API撕碎。

雨果

如果开发人员不能写出清晰、简洁和语法正确的评论，那么他们应该回去学习英语101。

我们有开发人员和(恐怖的)架构师，他们写得不连贯。当审查他们的文件时，他们会说"哦，别担心语法错误或拼写——这不重要"。然后他们想知道为什么他们复杂的垃圾文件变成了复杂的错误代码。

我告诉实习生，我指导你，如果你不能用口头或书面的方式传达你的伟大想法，你最好不要这些想法。

C++是一种好的语言

我几乎一个星期前就被另一个问题私奔了，因为他说C++不是一个很好的语言。所以现在我试着说相反的话。；)

不，说真的，我当时想做的，现在再试试，就是C++有很多缺点。很难否认。它是如此的复杂，以至于学好它实际上是你一生可以奉献的东西。它使许多常见的任务变得不必要的困难，允许用户在没有编译器给出警告的情况下，先将头插入一个行为不定义、代码不可移植的海洋中。

但许多人试图用的并不是无用的、陈旧的、过时的、令人讨厌的语言。它不应该被扫到地毯下而被忽视。没有它，世界就不会是一个更好的地方。它有一些独特的优势，不幸的是，隐藏在奇怪的语法背后，遗留的CRUFT，尤其是坏的C++教师。但他们在那里。

C++在C语言或其他"现代"语言中编程时，我非常怀念的许多特性。这里面有很多C和其他现代语言可以学习的。

它并不是盲目地关注OOP，而是探索和开创了通用编程。它允许令人惊讶的、富有表现力的编译时元编程生成非常高效、健壮和干净的代码。在C获得linq或lambda表达式之前，它从函数编程中吸取了差不多十年的经验。

它允许您在编译时通过静态断言和其他元编程技巧捕获大量错误，这大大简化了调试，甚至在某些方面胜过了单元测试。(我更愿意在编译时捕获错误，而不是在运行测试时在编译后捕获错误)。

变量的确定性破坏允许raii，一个非常强大的小技巧，使try/finally块和c的using块冗余。

虽然有人指责它是"委员会设计的"，但我会说是的，事实上，在这种情况下，这并不是一件坏事。看看Java的类库。又有多少类被弃用了？不应使用多少？有多少重复彼此的功能？有多少设计不好？

C++的标准库要小得多，但总体来说，它设计得很好，除了一个或两个小疣(例如，EDOCX1 1)，它的设计仍然很好。当一个特征添加到C++或它的标准库时，它会受到严格的审查。难道Java不能从中受益吗？.NET也同样，虽然它更年轻，而且设计得更好，但是它仍然积累了大量与现实不同步的类，或者设计得很糟糕。

C++有很多其他语言无法比拟的优点。这是一种很好的语言

源文件是20世纪的产物。

在函数/方法的主体中，将过程逻辑表示为线性文本是有意义的。即使逻辑不是严格线性的，我们也有很好的编程结构(循环、if语句等)，允许我们使用线性文本清晰地表示非线性操作。

但是没有理由要求我在不同的文件中划分类，或者在这些文件中按特定的顺序对函数/方法/字段/属性等进行排序。为什么我们不能把所有这些东西都扔到一个大数据库文件中，让IDE动态地对所有东西进行排序？如果我想按名称对成员排序，那么我将单击"成员"表中的"成员"标题。如果我想按可访问性对它们排序，那么我将单击可访问性标题。如果我想将类视为继承树，那么我将单击按钮来执行此操作。

也许可以从空间上看类和成员，就好像它们是虚拟世界中的某种实体。如果程序员愿意，IDE可以自动将彼此使用的类和成员放置在彼此附近，这样就很容易找到它们。图像能够放大和缩小这个虚拟世界。一直放大，你就可以给星系命名，其中有小类行星。放大到一个名称空间，你可以看到类行星与方法大陆和岛屿和内部类作为轨道卫星。放大到一个方法，你会看到…该方法的源代码。

基本上，我的观点是，在现代语言中，不管你把类放在什么文件中，或者你定义类成员的顺序如何，我们为什么还要被迫使用这些古老的实践呢？还记得Gmail出来谷歌说"搜索，不要排序"的时候吗？那么，为什么同样的原理不能应用于编程语言呢？

一个我已经辗转反侧一段时间了：

数据就是系统。

过程和软件是为数据而构建的，而不是反过来。

没有数据，过程/软件的价值很小。没有流程或软件，数据仍然有价值。

一旦我们了解了数据、它做什么、它如何交互、它在不同阶段存在的不同形式，只有这样才能构建一个支持数据系统的解决方案。

成功的软件/系统/过程似乎具有敏锐的意识，即使不是狂热地注意到数据在任何给定时刻的"位置"。

设计模式是石器时代编程语言设计的一个标志

他们有自己的目的。很多好的软件都是用它们构建的。但事实上，有必要将这些关于代码如何工作/应该如何工作的心理抽象的"处方"编纂起来，这说明缺乏能够为我们处理这种抽象的编程语言。

我认为，补救方法在于，语言允许您将越来越多的设计嵌入到代码中，方法是定义可能不存在或可能不具有一般适用性的语言构造，但在代码不断处理的情况下确实有意义。人们已经知道这个计划很多年了，而且计划宏有可能让大多数猴子雇佣尿裤子。

以狂热者的热忱和错误的假设，即他们是铁板一块的规则，把那些著名的格言从语境中规划出来，这真让我恼火。例如，"过早的优化是万恶之源"，正如这个线程所覆盖的那样。

在国际海事组织，许多技术问题和解决方案对环境非常敏感，而全球最佳实践的概念是一个谬论。

当我声称代码仅仅是我设计的一种表达时，我常常会被大声叫嚷。我非常不喜欢看到这么多开发人员在"动态"地设计系统的同时对其进行编码。

当这些牛仔中的一个从马上摔下来的时候，浪费的时间和精力是惊人的——10次中有9次他们碰到的问题可以通过一些预先设计工作来解决。

我觉得现代方法论并不强调设计在整个软件开发过程中的重要性。例如，当您甚至没有审查您的设计时，对代码审查的重要性！这太疯狂了。

牛仔编码员做得更多。

我一生都在创业的氛围中度过。如果没有牛仔编码员，我们将浪费无休止的周期来确保事情"正确"完成。

我们知道，基本上不可能放弃所有的问题。牛仔编码员直接处理这些问题，并被迫比那些试图抛弃它们的人更快地解决它们。

不过，如果你是牛仔编码，最好在别人维护之前先重构一下意大利面。我所知道的最好的使用连续重构。他们完成了大量的工作，不浪费时间去预测未来，通过重构，它变成了可维护的代码。

不管过程有多敏捷，它总是妨碍一个好牛仔。

Emacs较好

应始终使用基于1的数组，而不是基于0的数组。基于0的数组是不自然、不必要和容易出错的。

当我计算苹果、员工或小部件时，我从一开始，而不是从零开始。我教我的孩子们同样的东西。没有第0个苹果、第0个员工或第0个小部件这样的东西。使用1作为数组的基础更直观，更不容易出错。忘了加一减一地狱(就像我们过去常说的那样)。基于0的数组是计算机科学发明的一种非自然的构造——它们不反映现实，计算机程序应该尽可能反映现实。

用户不是白痴——你是。

我听过很多次开发人员说"白痴也是，白痴也是"，我的回答通常是"他可能是个白痴，但你允许他成为一个白痴"。

编程过程越多，代码就越差。

在我8年左右的编程生涯中，我注意到了一些事情，这看起来很荒谬。这是获得质量的唯一方法，就是雇佣质量开发人员，尽可能地从他们身上删除流程和形式。单元测试、编码标准、代码/同行评审等只会降低质量，而不会提高质量。这听起来很疯狂，因为相反的情况应该是正确的(更多的单元测试应该导致更好的代码，伟大的编码标准应该导致更可读的代码，代码评审应该提高代码的质量)，但事实并非如此。

我认为归根结底，我们称之为"软件工程"，实际上它是设计而不是工程。

一些数字证实了这一说法：

From the Editor

IEEE Software, November/December 2001

Quantifying Soft Factors

by Steve McConnell

...

Limited Importance of Process Maturity

...
In comparing medium-size projects
(100,000 lines of code), the one with
the worst process will require 1.43
times as much effort as the one with
the best process, all other things
being equal. In other words, the
maximum influence of process maturity
on a project’s productivity is 1.43. ...

... What Clark doesn’t emphasize is that
for a program of 100,000 lines of
code, several human-oriented factors
influence productivity more than
process does. ...

... The seniority-oriented factors alone
(AEXP, LTEX, PEXP) exert an influence
of 3.02. The seven
personnel-oriented factors
collectively (ACAP, AEXP, LTEX,
PCAP, PCON, PEXP, and SITE §) exert a
staggering influence range of 25.8!
This simple fact accounts for much of
the reason that non-process-oriented
organizations such as Microsoft,
Amazon.com, and other entrepreneurial
powerhouses can experience
industry-leading productivity while
seemingly shortchanging process. ...

The Bottom Line

... It turns out that trading process
sophistication for staff continuity,
business domain experience, private
offices, and other human-oriented
factors is a sound economic tradeoff.
Of course, the best organizations
achieve high motivation and process
sophistication at the same time, and
that is the key challenge for any
leading software organization.

§阅读文章了解这些缩略语的解释。

要生产优秀的软件，您需要领域专家和优秀的开发人员。

意见：框架和第三部分组件只能作为最后手段使用。

我经常看到程序员会立即选择一个框架来完成一项任务，而不必学习工作所需的底层方法。某些事情不可避免地会被打破，或者我们会找到一个我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要仔细考虑，框架就可以使用。

生成的文档几乎总是一文不值。

或者，作为推论：您的API需要为维护人员和用户提供单独的文档集。

实际上有两类人需要了解您的API：维护人员，他们必须了解您的实现的细节才能在他们的工作中发挥效力；用户，他们需要一个高级的概述、示例和他们所访问的每个方法的效果的详细信息。

我从来没有遇到过在这两个领域都成功生成的文档。一般来说，当程序员为工具编写注释以提取和制作文档时，他们的目标是在中间的某个地方——仅仅是足够的实现细节使用户感到厌烦和困惑，但还不足以显著地帮助维护人员，也不足以对用户提供任何真正的帮助。

作为一个维护人员，我宁愿有干净、清晰的注释，不被你的auto-doc工具所要求的任何奇怪的标记所迷惑，告诉我为什么你以你的方式写了那个奇怪的switch语句，或者这个看似多余的参数检查修复了什么bug，或者其他我需要知道的东西，以在我工作时保持代码的干净和无bug。它。我希望这些信息就在代码中，与它所涉及的代码相邻，所以我不必搜索你的网站，以发现它处于一种可以供阅读的状态。

作为一个用户，我总是希望有一个完整的、组织良好的文档(一组网页是理想的，但我也希望有一个结构良好的文本文件)，告诉我你的API是如何构建的，什么方法做什么，以及我如何完成我想用你的API做的事情。我不想在内部看到您编写的允许我工作的类，或者它们在其中的文件。我当然不想下载你的源代码，这样我就可以准确地知道幕后发生了什么。如果你的文件足够好的话，我就不必这么做了。

不管怎样，我就是这么看的。

我最有争议的编程意见是发现性能问题不是度量，而是捕获。

如果你在房间里猎捕大象(而不是老鼠)，你需要知道它们有多大吗？不！你要做的就是看。它们的巨大性使它们很容易被发现！不必先测量。

至少从gprof的论文开始，测量的概念就一直是常识。(Susan L.Graham等人，1982年)*一直以来，就在我们的眼皮底下，是一种非常简单和直接的方法来寻找值得优化的代码。

作为一个小例子，下面是它的工作原理。假设您从调用堆栈中随机抽取5个时间样本，并且碰巧看到5个样本中有3个样本的特定指令。这告诉你什么？

它告诉您程序将花费60%的时间来完成该指令要求的工作。去掉它会去掉60%：

粗略地说。

如果您可以删除该指令(或者调用的次数要少得多)，这大约是2.5倍的加速。(注意-递归是不相关的-如果大象怀孕了，它就不再小了。)然后你可以重复这个过程，直到你真正接近一个最佳状态。

• 这不需要测量精度、函数计时、调用计数、图形、数百个样本，以及任何一种典型的分析工具。

有些人在遇到性能问题时就使用这个方法，不知道有什么大不了的。

大多数人从来没有听说过它，当他们听说它的时候，认为它只是一种劣质的取样方式。但是它是非常不同的，因为它通过给出呼叫站点的成本(以及终端指令)来确定问题，这是墙时钟时间的百分比。大多数的轮廓仪(不是全部)都不这样做，不管它们是使用采样还是仪器。相反，他们给出了各种各样的总结性测量结果，这些测量结果充其量只是问题可能位置的线索。下面是对这些差异的更广泛的总结。

*事实上，论文声称gprof的目的是"帮助用户评估抽象的替代实现"。它并没有声称帮助用户找到需要替代实现的代码，而是在一个比函数更精细的级别。

我的第二个最有争议的观点是，如果不是很难理解的话。

客户并不总是对的。

在我处理的大多数情况下，客户是产品所有者，也称为"业务"。通常，开发人员只是编写代码，而不是试图提供产品的既得利益。有太多的误解认为IT部门是"公司内部的公司"，这是一堆垃圾。

我觉得我的职责是帮助企业表达他们的想法-在相互理解的情况下，我对了解企业感兴趣，这样我就可以提供尽可能最好的体验。这条路线意味着有时产品所有者会要求他/她认为是下一次计算革命，让某人要么同意这一事实，要么解释为什么没有人以某种方式做某件事的更可能的原因。这是互惠互利的，因为产品所有者理解进入产品的思想，开发团队理解他们做的不仅仅是吊带代码。

这实际上已经开始引导我们走上提高生产力的道路。怎样？由于双方意见不一致，沟通得到了改善，因此我们更有可能在过程中更早地聚在一起，为产品定义找到一个互利的解决方案。

如果你不知道就好了。但如果你连谷歌都不能搜索，你就被解雇了。

互联网是一种工具。如果你从中吸取教训，这不会让你变得更傻。

如果你的文本编辑器不能很好地完成代码，那你就是在浪费每个人的时间。

快速记住数千个参数列表、拼写和返回值(更不用说类结构和类似复杂的组织模式)是计算机擅长而人(相对而言)不擅长的任务。我全心全意地认为，让自己慢一点，避免使用小工具/功能狂热是提高效率和避免bug的好方法，但如果可以花费0，花30秒通过源代码或文档进行不必要的搜索根本没有好处…尤其是如果你只需要一个拼写(这比我们愿意承认的更频繁)。

当然，如果没有一个编辑器为您的语言提供这种功能，或者任务足够简单，以至于在加载更重的编辑器所需的时间内将其删除，没有人会告诉您Eclipse和90插件是正确的工具。但请不要告诉我，像1999年那样在你周围走动的H-J-K-L的能力确实比每次你需要方法签名时点击Escape节省了你更多的时间…即使你不觉得"黑客"这么做。

思想？

好的程序员讨厌编码

类似于"一个好的程序员是一个懒惰的程序员"和"代码越少越好"，但按照这一理念，我已经成功地编写了一些应用程序，否则可能会使用几倍的代码(并且需要几倍的开发时间)。简而言之：在编码之前先思考。我自己的程序中的大多数部分最终导致了后来的问题，它们是我真正喜欢编码的部分，因此代码太多，因此写得很差。就像这段。

好的程序员是设计师。

我发现编程使用的概念与设计相同(与艺术中使用的设计概念相同)。我不确定其他程序员是否也会发现同样的事情是真的；也许这是右脑/左脑的事情。太多的程序都很难看，从代码到命令行用户界面，再到图形用户界面，很明显，这些程序的设计者实际上不是设计者。

虽然在这种情况下，相关性可能并不意味着因果关系，但我注意到，随着我在设计方面的进步，我在编码方面的进步也越来越明显。在这两个地方都可以并且应该使用同样的过程来使事物变得合适和感觉正确。如果代码感觉不正确，它将导致问题，因为a)它是不正确的，或者b)您将假定它以一种稍后"感觉正确"的方式工作，然后它将再次是不正确的。

艺术和代码不在光谱的两端；代码可以在艺术中使用，它本身也可以是一种艺术形式。

免责声明：不幸的是，并不是我所有的代码都是漂亮的或"正确的"。

不要评论你的代码

注释不是代码，因此当事情发生变化时，很容易不更改解释代码的注释。相反，我更喜欢从代码中重构出垃圾代码，这样就没有理由发表评论了。一个例子：

到：

我唯一一次真正的评论是什么时候是一个托多或解释为什么

莫特没关系

不是每个人都是"摇滚明星"程序员；我们中的一些人之所以这样做是因为这是一种美好的生活，而且我们不关心所有最新的时尚和趋势；我们只是想做我们的工作。

我有争议的观点是：面向对象编程绝对是软件工程领域中最糟糕的事情。

OOP的主要问题是完全缺乏一个每个人都能同意的严格定义。这很容易导致具有逻辑漏洞的实现，或者像Java这样的语言，遵循这种OOP意味着的奇异的宗教教义，同时迫使程序员完成所有这些扭曲和"设计模式"，只是为了绕过特定的OOP系统的局限性。

因此，oop欺骗程序员，让他们认为他们正在取得巨大的生产力收益，而oop在某种程度上是一种"自然"的思考方式，同时迫使程序员输入大量不必要的样板文件。

既然没有人知道oop的真正含义，我们就浪费大量时间在关于x或y语言是否"真正oop"的琐碎争论上，那么对于一种被认为是"真正oop"的语言来说，什么奇异的货物崇拜语言特征绝对是"必不可少的"。

我们不应该要求这种语言或那种语言是"真正的面向对象的语言"，而应该观察实验所显示的语言特性，以实际提高生产力，而不是试图强迫它成为某种想象中的理想语言，或者确实迫使我们的程序符合"真正面向对象的程序"的柏拉图理想。"嗯"。

与其坚持我们的程序符合柏拉图式的"真正面向对象"的理想，不如专注于遵循良好的工程原理，使代码易于阅读和理解，以及使用具有生产力和帮助性的语言的特性，而不管它们是否足够"OOP"。

• Programmers often cannot correctly identify when some piece of data should only have two possible values
• The people who instruct programmers what to do，such as program managers or whoever writes the specs that programmers follow，often cannot correctly identify this either
• 即使一个数据的皮耶塞是正确的识别，因为只有两个可能的国家，保证可能不在未来。

(P)In these cases，using boolen variables leads to confusing code that can often be prevented by using listations.好的，好的。(P)例如好的，好的。(P)说一个程序是为一辆只有汽车和卡车的汽车编写软件。The programmer develops a thorough model of the business requirements for his software.了解到只有几类汽车焊是汽车和卡车，他更正了自己的身份，即他可以使用一种车辆内部的可变因素来表示车辆是一辆车还是一辆卡车。好的，好的。字母名称(P)The software is written so when EDOCX1 plus 0 is true a vehicle is a truck，and when EDOCX1 plus 0 is false the vehicle is a car.This is a simple check performed many times through the code.好的，好的。(P)没有麻烦的一切工作，直到有一天，当汽车载载着汽车的另一个死亡。The programmer has to update the software so it works correctly considering the dealership's business has changed.现在需要确定一辆车是一辆车，一辆卡车，还是一辆摩托车，三个可能的国家。好的，好的。(P)这项方案应如何执行？EDOC X1是一个波莉变量，所以它只能拥有两个国家。他可以从一个布尔到一些其他类型的国家，但这将打破现有的物流，并可能不是兼容的。The simpless solution from the programmer's point of view is to add a new variable to represent whether the vehicle is a motorcycle.好的，好的。字母名称(P)The code is changed so that when EDOCX1 plus 0 is true a vehicle is a truck，when EDOCX1 plus 4 is true a vehicle is a motorcycle，and when they're both false a vehicle is a car.好的，好的。(P)问题好的，好的。(P)有两个大问题与此解决：好的，好的。

• The programmer wants to express the type of the vehicle，which is one idea，but the solution used two variables to do so.一些未与《守则》取得一致的因素将是，如果方案拟订者使用的只是一个变量，而该变量又具体说明了第六个实体。
• 解决这一问题的办法是，增加一个新的Boolean并不意味着这一方案有任何改进之处，以便处理今后出现的这种情况。如果死亡之星堵住了公共汽车，方案将不得不通过增加新的Boolean而扭转所有这些步骤。

(P)这不是开发者的失误，因为企业要求修改其软件，要求它审查现有的守则。但是，使用Boolean变量，首先是他制定的法典缺乏灵活性，难以适应不了解未来的要求("未来——方案")。When he implemented the changes in the quickest way，the code because harder to read.使用布尔变量是最后一个过早优化。好的，好的。(P)解决好的，好的。(P)在第一个地方使用一个清单将有助于预防这些问题。好的，好的。字母名称(P)To accommodate motorcycles in this case，all the programmer has to do is add EDOCX1 universal 5 to EDOCX1 pensional 6，and add new logic to handle the motorcycle cases.没有新的变量需要补充。Existing logic should't be disrupted.还有一些人对《守则》不感兴趣，他们可以轻松地理解《车辆类型》是如何被破坏的。好的，好的。(P)Cliff Notes好的，好的。

不要使用只能存储两个不同状态的类型，除非您绝对确定两个状态总是足够的。如果将来可能需要两个以上状态，即使布尔值满足现有要求，也可以使用枚举。好的。好啊。

我经常在ASP.NET/VB.NET中工作，发现ViewState绝对是一场噩梦。它默认在大多数字段上启用，并在每个网页的开头产生大量编码数据。页面上控件的大小越大，viewstate数据就越大。大多数人并不关注它，但它创建了一组大数据，这些数据通常与页面上执行的任务无关。如果未使用所有ASP控件，则必须手动禁用该选项。要么就是这样，要么对一切都有自定义控件。

在我工作的一些页面上，有一半的页面是由viewstate组成的，这真的很遗憾，因为有更好的方法可以做到这一点。

就语言/技术观点而言，这只是我能想到的一个小例子。这可能是有争议的。

顺便说一下，您可能希望编辑此线程上的投票，它可能会受到一些影响；)

你并不总是需要一个数据库。

如果您需要存储少于几千个"东西"，并且不需要锁定，那么平面文件可以工作，并且在很多方面都更好。它们更便于携带，您可以在紧急情况下手动编辑。如果您的数据和业务逻辑之间有适当的分离，那么如果您的应用程序需要它，您可以很容易地用数据库替换平面文件。如果您考虑到这一点来设计它，它会提醒您在数据和业务逻辑之间有适当的分离。

——骨形态发生蛋白B

C(或C++)应该是第一个编程语言

第一种语言不应该是简单的语言，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。C是完美的，它迫使学生思考记忆和所有低级的东西，同时他们可以学习如何构造他们的代码(它有函数！)

C++有一个额外的优点：它真的很烂：这样学生就可以理解为什么人们必须提出Java和C语言。

这里有一个在我看来已经很多年了，但对每个人来说都是一个诅咒：在"发布"版本中用C(或C++)断言和EDCOX1×0""断绝几乎总是一个错误。(唯一的例外是时间或空间惩罚是不可接受的)。

理由：如果断言失败，程序将进入一种状态

• 从未测试过
• 开发人员无法为
• 开发人员已经有效地证明了不可想象。

然而，不知何故，"行业最佳实践"是，当与客户的数据进行实时运行时，事情应该变得混乱，并希望获得最佳结果。

所有源代码和注释应使用英语编写。

用英语以外的语言编写源代码和/或注释会降低代码的可重用性，并且如果您不理解它们所用的语言，则更难进行调试。

SQL表、视图和列也是如此，尤其是在使用缩写时。如果不缩写，我可以在线翻译表/列的名称，但是如果缩写了，我所能做的就是选择并尝试解密结果。

"邪恶"这个词在StackOverflow和Simulator论坛上被滥用和滥用。

使用它的人想象力太少。

更新的语言和托管代码并不能使一个糟糕的程序员变得更好。

如果以后要节省3倍的时间，那么只需编写一个抽象。

我看到人们有时会写下这些疯狂的抽象，我想，"为什么？"

除非抽象真的能节省你以后的时间，或者它能节省维护你代码的人的时间，否则人们似乎越来越多地在写意大利面代码。

我真的不喜欢人们告诉我使用getter和setter，而不是在您应该能够同时获取和设置类变量时公开变量。

如果要改变对象中的变量，我完全同意这一点，因此您不会得到这样的结果：a.b.c.d.e=某物；但我宁愿使用：a.x=某物；然后是a.s e t x(某物)；我认为a.x=某物；实际上更容易阅读，更漂亮，然后在同一个示例中设置/获取。

我看不出原因：

空集(t x){-> x＝x；}

T gx(){返回X；}

这是更多的代码，你一次又一次地做这些事情的时间会更多，而且只会让代码更难阅读。

最好的代码通常是你不写的代码。作为程序员，我们希望通过编写一些很酷的方法来解决每个问题。只要我们能解决一个问题，并且仍然给用户80%的想要的东西，而不引入更多的代码来维护和测试，我们就为waaaay提供了更多的价值。

类应该适合屏幕。

如果你必须使用滚动条来查看你所有的班级，那么你的班级太大了。

代码折叠和微型字体都在作弊。

我通常都有相当大的争议性、强烈和强烈的意见，所以这里只有几个：

"因为我们是微软的机构/合作伙伴/专家"从来都不是一个有效的论据。

我现在工作的公司首先将自己定位为微软的专家。所以前面提到的论点被抛到了相当多的地方，我还没有看到它有效的上下文。

我不明白为什么要在每个适用的领域推广微软的技术和产品，超越客户和员工的满意度，以及通用的语用学。

这只是我对软件业政治深深仇恨的基石。

Moss(Microsoft Office SharePoint Server)真是一派胡言。

有点像第一个观点，但我真的认为莫斯，因为它是，应该被赶出市场。它花费了上百万的人去许可和建立网络标准，让开发者们非常不高兴。我还没有看到一个莫斯项目有一个总体的积极成果。

然而，一个客户一次又一次地接近我们，要求我们提供moss解决方案。

开发人员不应该测试自己的软件

开发和测试是两个截然相反的学科。开发就是建设，测试就是拆除。有效的测试需要一种特定的心态和方法，在这种心态和方法中，您试图发现开发人员的错误，发现他们的假设中的漏洞，以及逻辑中的缺陷。大多数人，包括我自己，都无法将自己和他们自己的代码置于如此严格的审查之下，仍然保持客观。

如果你想写一个好的软件，那就离开你的电脑。

去和终端用户以及那些想要和需要软件的人一起玩。只有通过它们，您才能理解您的软件需要完成什么，以及它需要如何做到这一点。

• 询问他们对现有流程的爱与恨。
• 询问他们的过程的未来，它将走向何处。
• 出去看看他们现在使用什么，找出他们的使用模式。您需要满足并匹配他们的使用期望。看看他们还经常使用什么，特别是如果他们喜欢并且能够有效地使用它。匹配。

最终用户不会告诉RAT你的代码有多优雅，或者它使用什么语言。如果它对他们有用，他们喜欢使用它，你就赢了。如果这不能使他们的生活变得越来越好——他们恨它，你就输了。

穿着鞋子走一英里-然后去写你的代码。

我有一些……每件事都有例外，所以这些不难，也不快，但在大多数情况下确实适用。

没有人关心你的网站是否有效，XHTML是否严格，是否符合标准，或者是否有W3C徽章。

它可能会从其他Web开发人员那里为您赢得一些高分，但是其他浏览您的站点的人可能会给您一个垃圾，不管您是否验证了您的代码。绝大多数网络冲浪者都使用IE或火狐，而且由于这两种浏览器都能容忍非标准、非价格、无效的HTML，所以你真的不需要担心它。如果你为汽车经销商、技工、电台、教堂或当地的小企业建立了一个网站，你认为这些企业中有多少人关心有效的HTML？我冒昧地猜测它很接近0。

大多数开源软件都是无用的、过于复杂的废话。

让我安装一下我找到的这个好的OSS。看起来它应该做我想要的！哦，等等，首先我得安装另一个窗口管理器。好啊。然后我需要得到这个命令行工具并将其添加到我的路径中。现在我需要x、y和z的最新运行时。现在我需要确保这些进程正在运行。好的，很棒…所有配置。现在让我学习一套全新的命令来使用它。哦，酷，有人为它建立了一个图形用户界面。我想我不需要学习这些命令。等等，我需要这个库来让GUI工作。现在就下载吧。好了，现在开始工作了……废话，我弄不出这个糟糕的用户界面。

听起来熟悉吗？OSS是一个非常复杂的系统，因为它的复杂度很高，安装起来很复杂，你需要成为一个专家才能完成，而且大多数人都不知道该怎么做。如此之多的项目被搁置一边，其他项目则是如此之小，以至于很少有人会使用它们，而一些体面的项目(Flowplayer、OScommerce等)的源代码过于复杂和膨胀，以至于无法编辑源代码。您可以编辑源…如果你能找出400个文件中哪一个包含需要修改的代码。当你得知这400个问题时，你真的遇到了麻烦。

程序设计还处于初级阶段。

尽管多年来编程语言和方法发展得很快，但我们仍有很长的路要走。标志清晰：

显然，所有这些都在改善，但如果我们都能同意这是开始而不是结束，那就太好了。

新的Web项目应该考虑不使用Java。

我用Java做Web开发已经超过10年了。起初，与现有的替代方案相比，这是朝着正确的方向迈出的一步。现在，有比Java更好的选择。

这确实只是解决问题的"魔锤"方法的一个具体案例，但这是一个非常痛苦的案例。

开发人员都是不同的，应该这样对待。

开发人员不适合放在盒子里，也不应该被这样对待。解决问题的最佳语言或工具与开发人员的关系与解决问题的细节同样重要。

离塞尔科远点！！！！！

网址：http://www.dbdebunk.com/page/page/857309.htm

我认为使用代理主键比使用"自然"主键更有意义。

@ocdecio:fabian pascal给出了(在他书的第3章数据库管理实践问题中，在你链接的页面的第3点中引用)作为选择稳定的关键的标准之一(它总是存在并且不会改变)。当自然键不具有这样的属性时，出于明显的原因，必须使用代理键，您在注释中对此进行了提示。

你不知道他写了什么，你也不想去查，否则你会发现你确实同意他的观点。这里没有什么争议：他说"不要武断，要根据情况调整一般的指导方针，最重要的是，要用你的大脑，而不是武断的/食谱/古鲁的话"。

过度使用面向对象编程

有时候最好的答案就是简单的答案。

SQL本来可以而且应该做得更好。由于最初的规范是有限的，多年来，不同的供应商一直在向不同的方向扩展该语言。为MS-SQL编写的SQL与Oracle、IBM、MySQL、Sybase等的SQL不同。其他严重的语言(以C++为例)被仔细地标准化，这样在一个编译器下编写的C++通常会在另一个编译器下编译。为什么不能更好地设计和标准化SQL？

作为一种浏览器显示语言，HTML是一种严重失败的选择。我们花了数年时间通过css、xhtml、javascript、ajax、flash等对其进行扩展，以生成一个可用的UI，结果仍然不如您的基本厚客户端Windows应用程序好。另外，一个称职的Web程序员现在需要知道三种或四种语言才能创建一个合适的用户界面。

哦，是的。匈牙利符号是令人憎恶的。

大多数咨询程序员都很差劲，不应该允许他们编写生产代码。

我想大概60%或更多

大多数程序员都不擅长编程

(你说的是"有争议的")。

我坐在家里的办公室里，思考着一些编程问题，最后在书架上看到了我的"全谱只读存储器拆卸"副本，我想：

"今天有多少程序员可以编写频谱ROM中使用的代码？"

对于不熟悉它的人来说，频谱有一种基本的编程语言，可以做简单的二维图形(直线、曲线)、排序文件IO和浮点计算，包括转换函数，所有这些都是在16K的z80代码中完成的(一个<5MHZ的8bit处理器，没有fpu或整数乘法)。今天的大多数毕业生很难写出这么小的"你好世界"节目。

我认为问题在于，能够做到这一点的程序员的绝对数量几乎没有改变，但以百分比计算，它很快就接近于零。这意味着，随着越来越多的程序员进入该领域，正在编写的代码的质量正在下降。

在我目前工作的地方，有七个程序员，包括我自己。其中，我是唯一一个通过阅读博客、书籍、这个网站等和在家里"娱乐"编程来保持最新状态的人(我妻子经常对此感到惊讶)。还有一个程序员热衷于编写结构良好的代码(有趣的是，他使用Delphi做了很多工作)并重构糟糕的代码。其他的，嗯，不太好。关于它，你可以把它们描述为"蛮力"程序员——将强制不适当的解决方案，直到它们按照一种方式工作(例如，使用带有重复数组的C数组。调整大小以动态添加项，而不是使用列表)。

现在，我不知道我现在所在的地方是否是典型的，尽管从我以前的职位上我可以说是典型的。有了事后诸葛亮的好处，我可以看到一些对任何项目都毫无帮助的常见模式(缺乏对代码的同行评审)。

所以，7个程序员中有5个是垃圾。

斯基兹

应弃用大于运算符(>，>=)

我试着用小于大于的优先顺序编码了一段时间，结果还是卡住了！我不想回去，事实上，我觉得在这种情况下，每个人都应该按我的方式去做。

考虑常见的数学"范围"符号：0<=i<10

这在代码中很容易理解，并且您已经习惯了看到这样的习惯用法：变量在中间重复，中间由&；&；连接：

一旦你习惯了这种模式，你就永远不会看到愚蠢的样子

同样的方法。

由于操作数趋向于非递减顺序，长的关系序列变得更容易处理。

此外，对EDCOX1(0)的偏好体现在C++标准中。在某些情况下，operator=是用它来定义的！(如<代码> >！(A＜B＜B)

编程任务只有在它不可能的时候才有趣，直到你确信自己能够成功地解决它为止。

我想，这就是为什么我的许多项目最终都在一个名为"To_Be_Continued"的文件夹中完成了一半。

每个开发人员在开始构建电子系统之前，应该花几个星期甚至几个月的时间开发基于纸的系统。他们也应该被迫使用他们的系统。

开发一个好的基于纸张的系统是一项艰巨的工作。它迫使你考虑人性(繁琐的过程会被忽略，过于复杂的过程往往会崩溃)，并教会你欣赏简单的价值(新的工作放在这个托盘里，QA的工作放在这个托盘里，存档放在这个盒子里)。

一旦你学会了如何在纸上建立一个系统，建立一个有效的计算机系统通常会容易得多——人们实际上想要(并且能够)使用这个系统。

我们开发的系统并不是由一支训练有素的自动化部队来操控的；真正的人使用它们，真正的人接受管理者的培训，管理者也是真正的人，他们没有太多时间来浪费培训时间来训练他们如何跳出你的圈套。

事实上，对于我的第二点：

应该要求每个开发人员运行一个交互式培训课程，向用户展示如何使用他们的软件。

不应允许非开发人员管理开发人员。

更正：没有开发经验的员工不允许管理开发人员。

软件就像卫生纸。你花在上面的钱越少，屁股上的疼痛就越大。

也就是说，外包很少是个好主意。

我一直认为这是真的，但直到最近我才真正知道它的程度。我最近一直在"维护"(读作"修复")一些离岸代码，这是一个巨大的混乱。如果是内部开发的话，我们公司的成本很容易超过差异。

企业之外的人对你的商业模式天生就不太了解，因此对任何在你的企业内工作的系统进行编程都不会有那么好的工作。而且，他们知道他们不必支持它，所以除了半途而废，没有别的动机。

作为开发线经理，评估对我来说是一个有用的工具，可以计划我的团队正在进行的工作。

它们不是在特定日期交付功能的承诺，也不是推动团队更努力工作的一根棍子。

imho如果你强迫开发人员承诺评估，你会得到最安全的数字。

例如

I think a feature will probably take me around 5 days. There's a small chance of an issue that would make it take 30 days.

If the estimates are just for planning then we'll all work to 5 days, and account for the small chance of an issue should it arise.

However - if meeting that estimate is required as a promise of delivery what estimate do you think gets given?

如果开发人员的奖金或工作保障取决于是否达到预期，你认为他们给出的是最准确的猜测还是他们最确定会遇到的猜测？

我的这一观点与其他管理层存在争议，并被解释为我试图通过迂回的方式摆脱适当的目标，或我试图掩盖糟糕的绩效。每次都很难卖出，但我已经习惯了。

随机收集库克的格言…

• 最难学的语言是你的第二语言。

• 最难学习的操作系统是您的第二个操作系统，尤其是如果您的第一个操作系统是IBM大型机。

• 一旦你学会了几种看似不同的语言，你终于意识到所有的编程语言是相同的-只是语法上的细微差别。

• 虽然一个人在没有学会任何装配的情况下都能很好地生产和销售，没有它，任何人都不会对计算有本质的理解。

• 对于那些不太了解的程序员来说，调试器是最后的避难所。他们一开始在做什么。

• 如果不利用硬件内存管理，任何操作系统都不会稳定。

• 低级系统编程比应用程序编程容易得多。

• 有最喜欢的语言的程序员只是在玩。

• 首先编写用户指南！

• 政策和程序适用于那些缺乏主动性的人。

• (承包商的信条)：告诉他们需要什么。给他们想要的。确保支票清零。

• 如果你觉得编程不好玩，那就离开它，或者接受它，尽管你可能会生活在这样的环境中，你永远不会超过平均水平。

• 就像那些老家伙必须学习.NET方法名一样，你必须学会图书馆的电话。但是没有什么新的。程序员的生活就是不断适应不同的环境，你的腰带上挂的工具越多，你就越是多才多艺、适销对路。

• 你可能会在一开始就用小代码块来尝试一些想法，但是，一般来说，在你知道整个程序或者应用程序将被布局，你知道整个工作将完全一样广告。对于大多数至少具有一定复杂性的项目，我通常会把60%到70%的时间花在预先渗透思想上。

• 理解编程与语言几乎没有关系，与算法也没有任何关系。所有那些漂亮的极客，都有多年来人们想出的令人难忘的首字母缩写。只是对实现cat剥皮的不同方式。当你把所有的Oopines、Radology、Development Methodology 37和Best Practice 42，您仍然需要处理具有以下基本构造块：

  • 作业
  • 条件句
  • 迭代
  • 控制流
  • 输入输出

一旦你真的能把自己包裹起来，你最终会达到你的目的。从编程的角度来看，编写清单应用程序汽车零部件公司、图形实时TCP性能分析仪、数学模型一个恒星核心，或一个约会日历。

• 初学者使用小代码块工作。当他们获得经验时，它们使用越来越大的代码块。当他们获得更多的经验时，他们使用小代码块。

我不知道这是否真的有争议，但是如何处理：方法和函数名是您的代码可以拥有的最好的注释；如果您发现自己在写注释，把您正在注释的代码变成一个函数/方法。

这样做有一个令人愉快的副作用，那就是迫使你很好地分解你的程序，避免发表与现实不同步的评论，给你一些你可以改进代码库的东西，给你的代码留下新鲜的柠檬味。

90%的程序员都是非常糟糕的程序员，实际上我们所有人都没有工具来评估我们当前的能力水平(尽管我们通常可以回顾并认识到我们过去的糟糕程度)

我不想发表这篇文章，因为这会激怒所有人，我不是真的想得到一个负分或者其他什么，而是：

a)这不是问题的关键，而且

b)这条线索中的大多数"答案"都证明了这一点。

前几天我听到了一个很好的类比：编程能力的变化至少和运动能力一样大。我们中有多少人可以加入一个专业团队，真正提高他们的机会？

复制/粘贴是万恶之源。

编码不是打字

编写代码需要时间。大多数时候，在编辑器窗口中，您只是在查看代码，而不是实际键入。不是经常删除，而是经常删除您所写的内容。或者从一个地方搬到另一个地方。或重命名。

如果你长时间不停地敲打键盘，说明你做错了什么。

推论：每天写的代码行数并不是程序员生产力的线性度量，因为一天写100行的程序员很可能比写20行的程序员更好，但写5000行的程序员肯定是一个糟糕的程序员。

不要在数据库中使用存储过程。

它们最初很好的原因——安全性、抽象性、单一连接——都可以在中间层使用集成了许多其他优势的ORM来完成。

这一点肯定有争议。每次我提起它，人们都会把我撕成碎片。

这一个主要是网络相关的，但是…

为网页布局使用表格

如果我正在开发一个需要压缩性能的大型站点，我可能会考虑它，但是没有什么比表更容易让我在浏览器上看到一致性。我开发的大多数应用程序都是为大约100-1000个用户开发的，一次最多可能有100个用户。表的额外膨胀不会以任何方式杀死我的服务器。

递归最糟糕的是递归。

在允许初级程序员实际编写或修改代码之前，他们应该被指派做几个月的对象/模块设计和设计维护。

太多的程序员/开发人员在不了解好的设计元素的情况下达到了5年和10年的目标。当他们想要超越仅仅编写和维护代码的范围时，这可能是一个严重的问题。

像SharePoint这样的企业内部网框架让我觉得整个企业界都是一只头埋在沙子里的巨大鸵鸟。

我不仅在这里谈论Moss，我还与其他一些公司内部网产品合作过，而且绝对没有一个产品是伟大的，但是SharePoint(Moss)是迄今为止最糟糕的。

• 这些系统中的大多数并不容易弥合内部网和因特网之间的鸿沟。所以作为一个远程工作者，你必须进入VPN。外部客户只是没有机会直接掌握你的内部信息。当然，这个价格可以定为美元。
• 搜索能力总是令人遗憾的。很多时候其他部门根本不知道信息就在外面。
• 信息碎片，人们开始抵制工作流或回复电子邮件
• SharePoint开发是世界上最痛苦的开发形式。没有什么比SharePoint更差劲的了。我见过一些开发人员在和Moss一起工作一年多后打算退出它。
• 无论开发人员多么讨厌Moss，无论最基本的项目需要多长时间才能推出，无论结果看起来多么新手，无论内容多么不可搜索和分散：

每个人仍然继续使用和购买SharePoint，管理者仍然努力假装它不是撒旦的产物。

微格式

使用最初为可视化布局设计的CSS类-现在被分配给可视化和上下文数据是一种黑客攻击，充满了歧义。不是说功能不应该存在，而是修复该死的基础语言。HTML不是被黑客用来生成XML的，而是出现了XML语言。现在我们有了这些渴望脚本的孩子们，他们用黑客的HTML和CSS来做一些原本不该做的事情，这仍然很好，但我希望他们能把这些事情保持在自己的水平上，而不是制定一个标准。只不过是一些上流的屠夫！

除非您正在编写由不可重用的SQL查询组成的大型过程函数，否则请将数据库的存储过程移动到版本控制中。

编码是一门艺术

有些人认为编码是一门艺术，另一些人则认为编码是一门科学。

"科学"派认为，作为一种情况下获取最优代码的目标，编码就是研究如何获得最优代码的科学。

"艺术"派认为，有很多方法可以获得一种情况下的最佳代码，这个过程充满了主观性，根据自己的技能和经验明智地选择是一种艺术。

微软并没有很多人说的那么糟糕。

方法调用得到了句法上的优势，但声明没有。这是一个泄漏的抽象(按设计！)这会导致恼人的错误，包括运行时错误，在报告的参数数目中有一个明显的错误。

这个怎么样：

垃圾收集器实际上会损害程序员的工作效率，使资源泄漏更难查找和修复。

注意，我说的是一般的资源，而不仅仅是记忆。

让软件可配置是一个坏主意。

可配置软件允许最终用户(或管理员等)选择太多的选项，这些选项可能不是全部都一起测试过(或者更确切地说，如果有多个非常小的数字，我可以保证不会进行测试)。

因此，我认为配置硬编码(但不一定要避开常量等)的软件是一个好主意。使用合理的默认值运行，并且不允许更改它们。

一个很好的例子是Google Chrome上的配置选项数量——但是，这可能仍然太多了：)

我有争议的意见？Java并不吸引人，但Java API确实如此。为什么Java库坚持很难完成简单的任务？为什么他们不修复API，而是创建框架来帮助管理样板代码？这种观点可以适用于任何需要10行或更多行代码才能从文件中读取行的语言。

任何有足够能力的库都太复杂而不能使用，任何简单到可以使用的库都缺乏成为一个好的通用解决方案所需的功能。

我经常遇到这种情况。使用起来如此复杂的详尽的库，我把我的头发撕了下来，而简单易用的库却不能完全满足我的需要。

微软应该停止支持任何与Visual Basic有关的东西。

创建类似于患有疯牛病的椒盐卷饼的UML图的能力实际上不是一种有用的软件开发技能。

绘制代码图的关键是可视化连接，以查看设计的形状。但是，一旦你通过了一个相当低的复杂程度，视觉化就太多了，无法在精神上进行处理。仅当您坚持使用直线时，以图形方式建立连接才是简单的，这通常会使图表比沿着主要方向巧妙地分组和布线的连接更难阅读。

仅在广泛的交流目的中使用图表，并且只有当它们被理解为谎言时才使用图表。

是的，我知道这可能是对堆栈空间的无效使用，以及所有的爵士乐。但有时，与迭代算法相比，递归算法非常简单。当我可以在某个地方偷偷地使用递归函数时，我总是感到有点高兴。

大多数开发人员都不知道

是的。。你走吧。我已经说过了。我从我个人认识的所有开发人员那里发现了这一点。事实上，只有一把是好的。只有少数人知道应该测试代码…面向对象的开发方法实际上对您有所帮助。有人获得了开发人员的头衔，这让我非常沮丧，实际上他们所能做的就是复制粘贴一点源代码，然后执行它。

总之…我很高兴像StackOverflow这样的计划已经开始。这有利于开发人员思考。有更好的方法吗？我做得对吗？也许我可以用这种方法来加快速度，等等…

但是没有…大多数开发人员只是学习他们的工作需要的一种语言，并坚持使用它，直到他们自己变老，脾气暴躁，不知道发生了什么。他们只会得到一大笔薪水，因为他们比你大。

啊…在IT界，生活是不公平的，将来我会采取措施忽视这些人。万岁！

正在开发的绝大多数软件在收集需求时不涉及最终用户。

通常只有一些经理提供"需求"。

方法/函数参数的前提条件应该是语言的一部分，而不是程序员总是检查它。

对于一个好的程序员来说，语言不是问题。

这可能不是很有争议，但我听到很多其他程序员抱怨"他们为什么不都使用Delphi？""C·C吮吸"，"我会改变公司，如果他们强迫我使用Java"等等。我认为一个好的程序员是灵活的，能够用他一生中可能学过的任何编程语言编写好的程序。

代码生成错误

我讨厌那些要求您将代码生成(或复制粘贴)用于简单事物的语言，比如JavaBeans及其所有getter和setter。

C的自动属性是朝着正确的方向迈出的一步，但是对于具有字段、属性和构造函数参数的优秀DTO，仍然需要大量的冗余。

Web应用程序太糟糕了

我的网络连接非常慢。我对几乎所有非谷歌网站的体验，至少令人沮丧。为什么没有人再写桌面应用程序了？哦，我明白了。没有人愿意为学习操作系统如何工作而烦恼。至少，不是窗户。上一次你必须处理WM_PAINT时，你的头爆炸了。创建一个工作线程来执行一项长任务(我的意思是，用Windows的方式执行)完全超出了您的能力。什么叫回拨？哦，天哪！

垃圾收集很糟糕

不，实际上不是。但是它让程序员像其他东西一样吃力。在大学里，他们教给我们的第一门语言是视觉基础(原版)。之后，还有另一个过程，老师假装他们教我们C++。但损失已经造成了。没有人真正知道如何使用这个深奥的关键词delete做到了。在测试了我们的程序之后，我们或者得到了无效的地址异常，或者内存泄漏。有时候，我们两个都有。在我的1%的教职员工中，只有一个人能自己管理自己的记忆(至少他假装)，而且他在写这篇文章。其余的用vb.net编写程序，根据定义，这是一种糟糕的语言。

动态打字糟透了

当然，除非您使用的是汇编程序(这是一种值得称赞的动态类型)。我的意思是，动态的解释语言所带来的开销让它们很糟糕。别再愚蠢地认为不同的工具适合不同的工作了。C语言几乎适用于所有的东西(它速度快、功能强大、可移植)，当它不够快(不够快)时，总是有内联汇编。

我可能会想出更多的咆哮，但那将是以后，而不是现在。

vb6既可用于善也可用于恶。在编码过于复杂的时代，它是一个快速的应用开发环境。

我过去很讨厌vb，但我仍然嘲笑vb.net(可能是开玩笑的)，因为我不喜欢经典的vb，但是在它的时代，没有什么能比得上它完成工作。

需求分析、规范、设计和文档几乎永远都不适合"模板"。从一个空白文档开始，并开始输入"我将以这样的方式解释这一点，即如果我死了，其他人阅读了此文档，他们将知道我知道的一切，并且EE和"现在理解"，然后从那里开始组织，让章节标题和类似内容自然地发展，并适合您指定的任务，而不是局限于某些企业或学校对您的文档应该是什么样子的想法。如果你必须做一个图表，而不是使用别人的正式的、不可理解的系统，你最好只是画一个有意义的图表，上面有一个清晰的图例，它实际上指定了你试图指定的系统，并传达了开发人员在另一端(通常是你，几年后)需要的信息。接收。

[如果你必须这样做，一旦你写下了真正的文档，你可以经常把它放进你的组织强加给你的任何模板中。不过，您可能会发现自己必须添加章节标题和重复材料。]

这些类型文档的唯一时间模板有意义的是，当您有大量的任务时，这些任务在性质上非常相似，只是在细节上有所不同。"编写一个程序，允许通过此调制解调器组进行一次性远程登录访问，使用C-Kermit驱动终端连接nexus，"为容量使用生成历史趋势和预测报告"，"使用此库为所有报告提供传真功能"，"为2000年问题修复此代码"，"向此选项卡添加数据库触发器""填充由第三方供应商提供给我们的软件产品"不能全部用同一模板描述，不管人们怎么想。而且，我的大学课程试图教给我和我的同学的要求和设计图表技术不能用来指定一个简单的计算器程序(每个人都知道)。

编程既不是艺术也不是科学。这是一门工程学科。

这不是艺术：编程当然需要创造力。这不能使它成为艺术。代码的设计和编写是为了正常工作，而不是为了情感上的移动。除了空白，出于美观的原因更改代码会破坏代码。虽然代码可以是美丽的，但艺术不是主要目的。

这不是科学：科学和技术是不可分割的，但是编程是技术范畴。编程不是系统的学习和观察，而是设计和实现。

这是一门工程学科：程序员设计和构建东西。优秀的程序员设计功能。他们了解不同实现选项的权衡，并选择适合他们正在解决的问题的方案。

我敢肯定有人会喜欢解析单词，将艺术和科学的定义扩展到只包含编程或将工程限制在机械机器或硬件上。查字典。另外，"计算机编程艺术"是对艺术的一种不同用法，它意味着一种技能或工艺，如"对话艺术"中所说。编程的产品不是艺术。

有时跳上流行音乐是可以的

我厌倦了那些表现出"爷爷综合症"的人("你们这些孩子和你们新出现的测试驱动的发展"。过去十年中出现的每一项大技术都被吸干了。回到我的时代，我们写了真正的代码！"…你明白了)。

有时流行的东西之所以流行是有原因的。

如果你需要阅读手册，软件不够好。

简单明了：—)

大多数语言的拥护者制造了很多噪音。

罗伯·派克写道："数据占主导地位。如果您选择了正确的数据结构并组织得很好，那么算法几乎总是不言而喻的。数据结构而不是算法是编程的核心。"

由于现在有数百万条记录中有任何重要的数据，我认为良好的数据建模是最重要的编程技能(无论是使用RDBMS，还是像SQLite、Amazon SimpleDB或Google Appengine数据存储之类的东西)。

当所有的数据都存储在这样一个数据存储系统中时，不再需要复杂的搜索和排序算法。

我的一个：

长切换语句是您的朋友。真正地。至少在C。

人们倾向于避免和劝阻他人使用长切换语句，因为它们是"不可维护的"和"具有糟糕的性能特性"。

好吧，问题是在C中，switch语句总是自动编译为散列跳转表，所以实际使用它们是最好的方法？在性能方面，如果您需要简单的分支到多个分支。此外，如果案例语句是智能组织和分组的(例如按字母顺序)，那么它们根本就不可管理。

我认为，使用Try/Catch异常处理比使用简单的返回代码和相关的公共消息结构传递有用的错误消息更糟糕。

用try/catch块乱丢代码不是解决方案。

只是将异常传递到堆栈上，希望上面的内容可以做正确的事情，或者生成信息性错误不是解决方案。

如果认为您有机会系统地验证适当的异常处理程序是否能够处理透明或不透明对象中可能出错的任何问题，那么这是不现实的。(还可以考虑后期绑定/外部库，以及随着系统的发展，调用堆栈中不相关函数之间不必要的依赖性)

返回代码的使用很简单，可以很容易地系统地验证覆盖率，如果处理得当，将迫使开发人员生成有用的错误消息，而不是所有太常见的堆栈转储和模糊的I/O异常，这些异常对最终用户来说甚至是最有说服力的用户都是无意义的。

——

我最后的反对意见是使用垃圾收集语言。别误会我……我在某些情况下喜欢它们，但一般来说，对于服务器/mc系统，它们在我看来没有位置。

GC并不是一成不变的——即使是设计得非常好的GC算法，也可能基于依赖关系图中不明显的循环引用，对对象的依赖时间太长，甚至是永久性的。

遵循几个简单模式和使用内存记帐工具的非GC系统不存在这个问题，但确实需要比GC环境在预先设计和测试中做更多的工作。这里的权衡是，在非GC中测试期间，内存泄漏非常容易被发现，而查找与GC相关的问题条件则是一个更困难的命题。

内存是便宜的，但是当您泄漏昂贵的对象(如事务句柄、同步对象、套接字连接等)时会发生什么。在我的环境中，如果没有软件描述中的重要基础更改，您就无法想象您可以坐下来让语言为您担心这一点。

每发现一个缺陷都要纠正。不仅仅是"严重性1"缺陷；所有缺陷。

建立一种部署机制，使应用程序更新立即对用户可用，但允许他们选择何时接受这些更新。与用户建立直接的沟通机制，使他们能够报告缺陷，将他们的经验与更新联系起来，并提出改进建议。

通过积极的测试，可以在创建缺陷的迭代过程中发现许多缺陷；立即纠正这些缺陷可以减少开发人员的中断，这是创建缺陷的重要因素。立即纠正用户报告的缺陷，就构成了一个建设性的社区，以产品改进取代产品质量成为谈话的主题。实施用户建议的与您的愿景和策略一致的改进会产生热情的福音传道者社区。

汇编是最好的第一种编程语言。

Web服务绝对糟糕，而且不是未来的发展方向。他们效率低下，无法保证按订单交货。Web服务不应该在同时写入客户机和服务器的系统中使用。它们主要用于米老鼠混搭类型的应用程序。它们绝对不应该用于任何面向连接的通信。

由于Web服务是一个非常热门的话题，所以这种态度让我和同事们陷入了一些非常激烈的讨论中。任何要求使用Web服务的项目都注定要失败，因为很明显，它已经有了从管理层推下的荒谬需求。

开发人员过度使用数据库

开发人员通常将数据存储在一个DBMS中，该DBMS应该是代码或文件。我见过一个一列一行的表，它存储了"系统密码"(与用户表分开)。我见过数据库中存储的常量。我看到过数据库会让一个长大的编码员哭泣。

有一种神秘的敬畏，冒犯的程序员对DBMS有一种敬畏——数据库可以做任何事情，但他们不知道它是如何工作的。DBA练习黑人艺术。它还允许责任转移："数据库太慢"，"数据库做到了"，其他借口也很常见。

不加检查，这些编码人员继续在数据库中开发数据库，在系统中开发系统。(这个反模式有个名字，但我忘了它是什么。)

最好的程序员在调试器中跟踪所有代码并测试所有路径。

好。。。手术说有争议！

一个好的开发人员需要知道的不仅仅是如何编码

自己写是一个有效的选择。

根据我的经验，当涉及到使用第三方代码来解决问题时，似乎有太多的热情。自力更生解决问题的选择通常不会让人产生误解。虽然我没搞错，但我不是在宣传从不使用图书馆。我要说的是：在您考虑使用的可能的框架和模块中，添加自己实现解决方案的选项。

但为什么要编写自己的版本呢？

• 不要重新发明轮子。但是，如果你只需要一块木头，你真的需要一个完整的车轮吗？换句话说，您真的需要OpenCV来沿轴翻转图像吗？
• 妥协。为了能够使用特定的库，通常必须在设计上做出妥协。您必须包含的更改量是否值得您接受的功能？
• 学习。你必须学会使用这些新的框架和模块。你要花多长时间？值得你花点时间吗？学习要比实施要花更长的时间吗？
• 成本。并非每件事都是免费的。不过，这包括你的时间。考虑一下你将要使用这个软件会节省你多少时间，如果它值得的话，它的价格是多少？(还要记住，你必须花时间学习它)
• 你是个程序员，不是…一个只把东西放在一起的人(对不起，没想到有什么机智的东西)。

最后一点是有争议的。

过早的优化并不是万恶之源！缺乏适当的计划是万恶之源。

记得那把旧的海军锯子吗？

Proper Planning Prevents P*ss Poor
Performance!

编程：这是一项有趣的工作。

我似乎看到了两组通用的开发人员。那些不爱它，但又能干又有钱的人。另一个喜欢它的群体有点让人毛骨悚然。这似乎是他们的生活。

我只是觉得这是一份报酬丰厚的工作，通常是有趣和有趣的。每天每分钟都有学习新事物的各种空间。我想不出我更喜欢的工作了。但这仍然是一项工作。我们会做出妥协，你所生产的产品也不会总是那么好。

因为我的鼓手会在海滩上喝啤酒或和我的孩子们玩。

在我的工作(拷贝保护系统)中，汇编程序编程是必不可少的，我曾与许多HLL拷贝保护系统合作过，只有汇编程序才给你真正的能力来利用代码中隐藏的所有可能性(如代码突变、低级的东西)。

此外，只有汇编程序编程才能实现许多代码优化，查看任何视频编解码器的源代码，源代码是用汇编程序编写的，并优化为使用mmx/sse/sse2操作码。无论什么，许多游戏引擎都使用汇编程序优化的例程，甚至Windows内核也使用sse优化的例程：

所以，如果你下次听到汇编程序死了，想想你看过的最后一部电影或者你玩过的游戏(以及它的版权保护)。

代码就是设计

不断测试

您必须编写测试，并且必须首先编写它们。编写测试会改变编写代码的方式。它让你想一想你想让它实际做什么，然后你就跳进去写些什么，除了你想让它做什么以外，什么都能做。

它也给你目标。看着你的测试变绿，你会有一点额外的信心，那就是你已经完成了一些事情。

它还为编写边缘案例的测试提供了基础。因为您首先是针对测试编写代码的，所以您的代码中可能有一些钩子需要测试。

没有理由不测试您的代码。如果你不这样做，你就是懒惰。我还认为您应该首先进行测试，因为这样做的好处超过了用这种方式编写代码所需的额外时间。

有时您必须取消数据库的规范化。

这一观点在大多数程序员中并不适用，但有时您必须牺牲一些东西，如规范化来提高性能。

关系数据库对于Web应用程序来说很糟糕。

例如：

• 线程注释
• 标签云
• 用户搜索
• 维护记录视图计数
• 提供撤消/修订跟踪
• 多步骤向导

关系数据库系统将是最好的，因为切片面包…

…当我们(希望)得到它们时，就是这样。SQL数据库太糟糕了，不好笑。

我觉得有趣的是(如果是SAD的话)经过认证的DBA认为SQL数据库系统是关系数据库系统。对所述认证的质量有充分的说明。

困惑的？读一下C.J.Date的书。

编辑

为什么称之为关系型，这个词是什么意思？

现在，一个拥有强大(见鬼，任何)数学背景的程序员(或认证DBA，wink)是一个例外，而不是普通情况(我也是普通情况的一个实例)。带有表、列和行的SQL，以及被称为实体/关系建模的笑话，仅仅是对伤害的侮辱。难怪人们错误地认为关系数据库系统之所以被称为关系数据库系统是因为某些关系(外键？)在实体(表)之间是如此普遍。

事实上，关系源于关系的数学概念，因此与集合理论和函数(在数学中，不是任何编程，意义上)密切相关。

[http://en.wikipedia.org/wiki/finitary_relationship][2]：

In mathematics (more specifically, in set theory and logic), a relation is a property that assigns truth values to combinations (k-tuples) of k individuals. Typically, the property describes a possible connection between the components of a k-tuple. For a given set of k-tuples, a truth value is assigned to each k-tuple according to whether the property does or does not hold.

An example of a ternary relation (i.e., between three individuals) is:"X was-introduced-to Y by Z", where (X,Y,Z) is a 3-tuple of persons; for example,"Beatrice Wood was introduced to Henri-Pierre Roché by Marcel Duchamp" is true, while"Karl Marx was introduced to Friedrich Engels by Queen Victoria" is false.

维基百科非常清楚：在一个SQL DBMS中，这样的三元关系将是一个"表"，而不是一个"外键"(我可以随意重命名关系的"列"：x=who，y=to，z=by)：

此外，它还将包含(可能包括其他行)此"行"：

但不是这个：

关系数据库字典：

relation (mathematics) Given sets s1, s2, ..., sn, not necessarily distinct, r is a relation on those sets if and only if it's a set of n-tuples each of which has its first element from s1, its second element from s2, and so on. (Equivalently, r is a subset of the Cartesian product s1 x s2 x ... x sn.)

Set si is the ith domain of r (i = 1, ..., n). Note: There are several important logical differences between relations in mathematics and their relational model counterparts. Here are some of them:

• Mathematical relations have a left-to-right ordering to their attributes.
• Actually, mathematical relations have, at best, only a very rudimentary concept of attributes anyway. Certainly their attributes aren't named, other than by their ordinal position.
• As a consequence, mathematical relations don't really have either a heading or a type in the relational model sense.
• Mathematical relations are usually either binary or, just occasionally, unary. By contrast, relations in the relational model are of degree n, where n can be any nonnegative integer.
• Relational operators such as JOIN, EXTEND, and the rest were first defined in the context of the relational model specifically; the mathematical theory of relations includes few such operators.

And so on (the foregoing isn't meant to be an exhaustive list).

我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员我们需要违反MVC设计模式的规则，以使站点运行更快。对于开发人员来说，这是一个艰难的买卖，他们通常不愿意为任何事情牺牲设计良好的代码。但是在构建Web应用程序时，性能是我们的首要任务，因此有时我们必须在框架中做出让步。

例如，视图层不应该直接与数据库通信，对吗？但是，如果您正在生成大型报告，应用程序将使用大量内存将数据传递到模型和控制器层。如果您有一个支持光标的数据库，它可以使应用程序从视图层直接访问数据库更快。

绩效胜过发展标准，这是我有争议的观点。

使用单元测试作为最后的手段来验证代码。

如果您想验证代码是否正确，我更喜欢以下技术而不是单元测试：

对于其他一切，都有单元测试。

没有面向对象编程这样的东西。

最佳实践是一种危险，因为它们要求我们用口号来代替思考。

在我参与过的许多项目中，一开始就花了大量的精力用MicrosoftWord编写"规范"。这个过程在一次"签准"会议上达到了高潮，当时项目上的大人物都参与进来了，在那次会议之后，再也没有人看过这个文件。这些文档完全是在浪费时间，并不能反映软件的实际设计。这并不是说应用程序设计中没有其他有价值的工件。它们通常包含在索引卡、白板快照、鸡尾酒餐巾纸和其他类似的媒体上，这些媒体为应用程序的设计提供了一种时间表。这些通常是应用程序的真实规格。如果你要写一个Word文档(我不是特别说你应该)在项目结束时完成它。至少它可以准确地表示代码中所做的工作，并可能帮助一些人，比如QA团队或下一个版本开发人员。

最简单的方法是最好的方法

程序员喜欢解决假定的或推断的需求，这些需求会增加解决方案的复杂性。

"我认为这段代码将成为性能瓶颈，因此我将添加所有这些额外的代码来缓解这个问题。"

"我假设用户要做X，因此我将添加这个非常酷的附加功能。"

"如果我让我的代码解决这个不需要的场景，这将是一个很好的机会，可以使用我一直感兴趣的新技术。"

实际上，满足需求的最简单的解决方案是最好的。当出现新的需求或问题时，这也给了您最大的灵活性，使您能够将解决方案带向新的方向。

javascript是一种"杂乱"的语言，但上帝保佑我，我喜欢它。

不是真正的编程，但我不能仅仅为了它而忍受CSS布局。它具有反效果，令人沮丧，并且使维护成为浮动和利润率的噩梦，在这种情况下，更改单个元素的位置可能会使整个页面失去平衡。

这绝对不是一个流行的观点，但是我在20分钟内就完成了我的表格布局，而CSS专家花费数小时来调整行高、边距、填充和浮动，只是为了做一些基本的事情，比如垂直居中一段。

现代C++是一种优美的语言。

好了，我说了。很多人真的讨厌C++，但老实说，我发现现代C++与STL /Boost风格编程在大多数时候都是一种非常有表现力、优雅和令人难以置信的语言。

我认为大多数讨厌C++的人都是基于OO的坏经验。C++并不能很好地处理OO，因为多态通常依赖于堆分配的对象，C++没有自动垃圾收集。

但是C++在真正的通用库和函数编程技术中真正闪耀，这使得构建难以置信的大型、高度可维护的系统成为可能。很多人说C++试图做所有的事情，但最终却什么也不做。我可能会同意它不像其他语言那样做OO，但是它比任何其他主流的基于C的语言做通用编程和函数式编程更好。(C++0X将进一步强调这一事实。)

我还感谢C++如何让我在必要时获得低级，并提供对操作系统的完全访问。

加上RAII。说真的。当我用其他基于C的语言编程时，我真的很怀念析构函数。(不，垃圾收集不会使析构函数无效。)

大多数的面试问题都是毫无意义的。尤其是那些由程序员计算出来的。

这是一个常见的情况，至少根据我和我的朋友的经验，在那里一个自大程序员，问你一些他花了几周时间搜索的棘手的问题。有趣的是，你回到家，一分钟内用谷歌搜索。就像他们经常试图用他们的精密武器打败你，而不是检查你是否是一个全面、务实的团队合作者。

同样愚蠢的是，当你被要求提供高度可访问的基础知识时，比如："哦，等等，让我看看你是否能在一张纸(sic！)上伪代码insert_name_here算法。".在申请高级编程工作时，我真的需要记住它吗？我应该有效地解决问题还是难题？

我有争议的观点：OO编程被高估了很多(并且被视为一颗银弹)，而它实际上只是工具箱中的另一个工具，没有更多！

社交技能比技术技能更重要

与那些不优秀的优秀程序员相比，拥有良好社会技能的优秀程序员将拥有更成功的执行者。

有争议吗？我认为C++流使用< <和> >这一事实。我讨厌它。他们是轮班操作员。以这种方式重载它们显然是不好的做法。这让我想杀任何一个想到这是个好主意的人。GRRR

工具、方法、模式、框架等不能代替经过适当培训的程序员。

我厌倦了与那些认为最新的工具、方法、模式或框架是银弹的人(主要是经理)打交道，他们认为这将消除雇佣有经验的开发人员来编写他们的软件的需要。虽然，作为一个以拯救风险项目为生的顾问，我不应该抱怨。

"评论是谎言"

评论不会运行，很容易被忽略。最好用单元测试说明的清晰、重构的代码来表达意图。(当然是编写的单元测试TDD…)

我们不写注释，因为它们冗长而晦涩，不知道代码中到底发生了什么。如果您觉得需要注释-找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释为止…

…我从极限编程中学到了一些东西(当然，假设您已经建立了清理代码的团队规范…)

例外应仅在真正例外的情况下使用。

在我最近工作过的项目中，异常的使用似乎很猖獗。

下面是一个例子：

我们有拦截Web请求的过滤器。过滤器调用一个筛选程序，筛选程序的工作是检查请求是否有某些输入参数并验证这些参数。设置要检查的字段，抽象类确保参数不为空，然后调用由特定类实现的screen()方法来执行更多扩展验证：

checkFieldExistance(req)方法从不返回false。如果没有字段丢失，则返回true；如果字段丢失，则引发异常。

我知道这是一个糟糕的设计，但问题的一部分在于，这里的一些架构师认为每次遇到意外情况时都需要抛出一个异常。

另外，我知道checkFieldExistance(req)的签名确实会引发异常，这几乎是我们所有方法都会引发的——所以我没有想到该方法可能会引发异常而不是返回false。直到我把代码挖掘出来，我才注意到它。

因为有上百个答案，我的答案可能最终会是未读的，但这是我最讨厌的。

对于程序员来说，这个网站是一个非常棒的资源，但是如果你在寻找XHTML/CSS帮助的话，它绝对是一个糟糕的地方。即使是这里的优秀Web开发人员也在分发指向90年代优秀资源的链接！

当然，XHTML和CSS很容易学习。然而，你不仅仅是在学习一门语言！您正在学习如何很好地使用它，很少有设计师和开发人员能够做到这一点，更不用说程序员了。我花了很长时间才成为一名有能力的设计师，甚至更久才成为一名优秀的开发人员。我从10岁起就可以用HTML编码，但这并不意味着我很好。现在，我是一个有能力的设计师在程序，如photoshop和Illustrator，我完全能够写一个好的网站记事本，并能够写一些语言的基本脚本。不仅如此，我对搜索引擎优化技术有着敏锐的嗅觉，可以很容易地告诉你大多数人哪里出错了(提示：获取一些好的内容！).

此外，这个地方是一个糟糕的网站标准建议资源。您不应该只编写代码来在不同的浏览器中工作。您应该始终遵循该标准，以便将来验证您的代码。当下一次浏览器更新到来时，您在网站上使用的修复通常会中断。不仅如此，好的浏览器还是遵循标准。最后，IE被允许破坏互联网的原因是你通过为IE编写网站代码来实现的！如果你继续为火狐做这些，那么我们又会输！

如果你认为基于表的布局同样好，如果不比CSS布局好，那么你就不应该被允许谈论这个主题，至少在没有我先把你打倒的情况下。另外，如果你认为W3学校是最好的资源，那么你就是大错特错了。

如果你是一个网页设计/开发新手，不要为这个地方操心(这里到处都是程序员，而不是网页开发人员)。去一个好的Web设计/开发社区，比如SitePoint。

1。你不应该一直遵循网络标准。

2。您不需要对代码进行注释。

只要陌生人能理解。

根据我得到的反馈量，我最有争议的观点显然是程序员并不总是读他们声称读过的书。紧接着，我认为受过正规教育的程序员比自学的同一个程序员更好(但不一定比自学的不同程序员更好)。

我坚信非托管代码不值得麻烦。额外的可维护性费用与查找内存泄漏有关，即使最好的程序员偶尔引入，也远远超出了从C++语言中获得的性能。如果Java、C等无法获得所需的性能，则购买更多的机器。

VB吸吮虽然一般来说没有太大的争议，但当你在一个VB的房子里工作的时候

全球和/或独生子女并非天生邪恶

我来自更多的系统管理员，Shell，Perl(和我的"真实"编程)，PHP类型的背景；去年我被扔进Java开发GIG。

单身汉是邪恶的。地球人是如此邪恶，他们甚至不被允许。然而，Java有像AOP这样的东西，现在有各种各样的"依赖注入"框架(我们使用谷歌Guice)。少了点，但我的东西肯定会给你什么？全球。嗯，谢谢。

我认为在C中使用区域完全可以折叠代码，而在VS中，太多人试图说它隐藏了您的代码，使得很难找到东西。但是，如果您正确地使用它们，它们对于识别代码的各个部分非常有帮助。

别害羞，要破例。异常是一种非常有效的信号故障方法，并且比任何返回代码系统都清楚。"异常"与这种情况发生的频率无关，而一切都与类所认为的正常执行条件有关。当除数为零时抛出异常是很好的，不管这种情况发生的频率如何。如果可能出现问题，请保护代码，这样就不会使用不正确的参数调用该方法。

关系数据库浪费时间。改用对象数据库！

关系数据库供应商试图愚弄我们相信，世界上唯一可扩展、持久和安全的存储是关系数据库。我是经认证的DBA。您是否曾花费数小时尝试优化查询，却不知道出了什么问题？关系数据库不允许您在需要时创建自己的搜索路径。你把对你的应用程序速度的大部分控制权交给了你从未见过的人，他们并不像你想象的那么聪明。

当然，有时在维护良好的数据库中，他们会对复杂的查询给出快速的答案。但你为此付出的代价太高了！您必须在每次想要读取数据条目时编写原始SQL之间做出选择，这很危险。或者使用对象关系映射器，这会增加更多的复杂性和超出您控制范围的内容。

更重要的是，你被积极地禁止提出智能搜索算法，因为到数据库的每一次往返都要花费你大约11毫秒的时间，太多了。假设您知道这个超级图算法，它将回答一个特定的问题，甚至可能在SQL中无法表达！，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要考虑将它与关系数据库相结合，因为枚举一个大表需要花费您几个小时！

将其与sandstonedb或gemstone进行比较！如果你进入Java，就给D4O一个镜头。

所以，我的建议是：使用一个对象数据库。当然，它们并不完美，有些查询速度会变慢。但你会惊讶有多少会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您真的需要某个查询的速度，那么对象数据库有您应该信任的查询优化器：您的大脑。

反射在生产代码中没有位置

反射破坏静态分析，包括重构工具和静态类型检查。反射也打破了开发人员对代码的正常假设。例如：向类中添加一个方法(不会在类中隐藏其他方法)不应该有任何效果，但是当使用反射时，其他代码可能会"发现"新方法并决定调用它。实际上，确定此类代码是否存在是很难的。

我认为在代码生成器中使用反射和测试是很好的。

是的，这确实意味着我试图避免使用反射的框架。(太糟糕了，Java缺少合适的编译时元编程支持)

两个大脑比一个大脑思考得好

我坚信，在提高代码质量和编程效率方面，结对编程是首要因素。不幸的是，对于管理层来说，这也是一个极具争议的问题，他们认为"更多的人手=>更多的代码=>$$！"

您不能通过计算代码行来衡量生产力。

每个人都知道这一点，但出于某种原因，这种做法仍然存在！

你不应该以你发现的第一种方式来解决编码"有效"的问题。

我真的不认为这会引起争议，但确实如此。人们从代码中的其他地方，在线上，或者从1999年出版的一本老书"在3.14159分钟内自学高级能力sqljava beansserver"中看到一个例子，他们认为自己知道一些东西，并将其复制到代码中。他们不会通过示例了解每一行的作用。他们不会考虑他们程序的设计，看看是否有一种更为有组织或更自然的方法来做同样的事情。他们不会试图让自己的技能设置保持最新，以了解他们使用的思想和方法在上一个千年的最后一年被弃用。他们似乎没有经验去了解他们正在复制的内容多年来给程序员造成了特别可怕的维护负担，并且他们可以通过更多的思考来避免。

事实上，他们甚至没有意识到可能有不止一种方法可以做一些事情。

我来自Perl世界，其中的一个口号是"有不止一种方法可以做到这一点"。(tmtowtdi)那些草草看了Perl的人已经把它写成"只写"或"不可读"，很大程度上是因为他们看了我上面描述的思维方式的人写的蹩脚的代码。这些人对设计、可维护性、组织、减少代码重复、耦合、内聚、封装等都没有考虑，他们写得很糟糕。这些人以每种语言都有编程，而且很容易学习语言，有很多方法可以做事情，给他们足够的绳子和枪来射击和吊死自己。同时。

但是，如果您在Perl世界中停留的时间比草率的观察要长，并且观察社区中的长时间工作者正在做什么，那么您会看到一件了不起的事情：优秀的Perl程序员会花一些时间寻找最佳的方法来做一些事情。当他们命名一个新的模块时，他们四处征求建议，并从人们身上激发他们的想法。他们把代码分发出去，以便得到查看、批评和修改。如果他们必须做一些令人讨厌的事情，他们将它以尽可能小的方式封装在一个模块中，以便以更有组织的方式使用。同一想法的几种实现可能会停留一段时间，但它们竞争的是精神共享和市场份额，它们竞争的方式是努力做到最好，其中很大一部分是使自己易于维护。真正优秀的Perl程序员似乎很难思考他们在做什么，并寻找最好的方法来做事情，而不仅仅是抓住第一个在他们大脑中穿行的想法。

今天我主要在Java世界中编程。我看到了一些非常好的Java代码，但我也看到了很多垃圾，而且我看到了我在一开始描述的更多的心态：人们在第一个看起来很难工作的代码集中，不理解它，而不思考是否有更好的方法。

你会在每种语言中看到这两种心态。我并不是试图具体地攻击Java。(实际上我在某些方面很喜欢它…也许这应该是我真正有争议的观点！)但我开始相信，每个程序员都需要花上好几年的时间来使用tmtowtdi风格的语言，因为尽管传统的智慧认为这会导致混乱和糟糕的代码，但实际上它似乎会让人们明白，你需要考虑你所做的事情的影响，而不是信任你。你的语言是为了让你不费吹灰之力做正确的事情而设计的。

我认为你可能会在另一个方向上走得太远：即完全忽略你真正的需求和目标的完美主义(通常是你企业的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，而不需要学会投入比平均水平更大的精力去思考如何找到最好的(或者至少是最好的)编码方式。

垃圾收集被高估了

许多人认为在Java中引入垃圾收集是与C++相比最大的改进之一。我认为引言最好是非常小的，写得好的C++代码在适当的地方做所有的内存管理(像RAII这样的技术)，所以不需要垃圾回收器。

在许多情况下，使用regexs解析HTML是很好的

每当有人发布关于栈溢出的问题，询问如何用regex实现一些HTML操作时，第一个答案是"regex是一个不足以解析HTML的工具，所以不要这样做"。如果发问者试图建立一个网络浏览器，这将是一个有用的答案。然而，通常，发问者希望做一些事情，比如向某个域的所有链接添加rel标记，通常是在可以对传入标记的样式做出某些假设的情况下，这对于regex来说是完全合理的。

不是工具，是你

每当开发人员尝试做一些新的事情，比如做UML图、任何类型的图表、项目管理，他们首先会寻找完美的工具来解决这个问题。在无休止的搜索后，发现不合适的工具，他们的动机就会匮乏。剩下的就是抱怨缺少可用的软件。这是一种洞见，即计划的组织在缺少一个软件的情况下死亡。

好吧，只有你自己在和组织打交道。如果你习惯于组织，你可以使用或不使用软件(大多数情况下不用软件)。如果你不习惯组织，没人能帮你。

因此，"没有合适的软件"只是一个根本没有被组织起来的最简单的借口。

意见：不应该有任何编译器警告，只有错误。或者，以不同的方式编写代码时，应该始终使用-werror。

原因：要么编译器认为它是应该纠正的，以防它是一个错误，要么它不需要修复，在这种情况下，编译器应该关闭。

有太多的程序员编写了太多的代码。

变量名称带有下划线

甚至更糟

大写的变量名称带有血腥下划线

应该全局删除…带着偏见！茶花只是很好。(GLOLBAL常量不可承受)

goto语句供11岁以下的开发人员使用

任何不支持指针的语言都不值得命名

净值=膨胀微软为网站开发所做努力的最好例子(无表情Web 2)是有史以来写过的缓慢膨胀的cr@pw@re的最好例子。(请尝试使用Web Studio)

回应：好吧，让我来讨论一下下划线问题。从您提供的C链接：

-全局常量应全部为带"u"分隔符的大写。我同意这一点，因为这很明显

-以网络包为例。注意abc中的c和key中的k是如何混淆的。有些人不介意这一点，而另一些人则讨厌这一点，所以你会在不同的代码中找到不同的策略，所以你永远不知道该怎么称呼某个东西。

我属于前一类。我非常仔细地选择名字，如果你一眼就看不出K是键的，那么英语可能不是你的第一语言。

• C函数名

  • 在C++项目中，很少有C函数。
  • 对于C函数，使用所有小写字母的gnu约定，其中"u"作为单词分隔符。

正当理由

例子

int一些血腥的功能{}

这些"标准"和惯例只是时间上的任意决定。我认为，虽然它们有一定的逻辑意义，但它们会把代码弄得杂乱无章，而且会使代码变得短小、易读、笨拙、冗长、杂乱无章。

C被采用为事实上的标准，不是因为它是友好的，而是因为它是普遍的。我可以用一种语法友好的高级语言在20行中编写100行C代码。

这使得程序流很容易阅读，正如我们所知，一年或更长时间后重新访问代码意味着跟踪整个地方的breadcrumb跟踪。

我确实使用了下划线，但是对于全局变量，它们是非常少的，而且非常明显。除此之外，一个精心设计的camelcaps()函数/变量名还没有让我失望！

调试器是一根拐杖。

这是如此的有争议，以至于我都不像以前那样相信它。

反对者：我花了更多的时间来加快其他人大量的代码，所以任何有助于"我是怎么到这里来的"和"发生了什么"的东西，无论是尸检前还是尸检后都是有帮助的。

但是，我很高兴地支持这样一个观点：如果你不理解你自己开发的或者你已经熟悉的代码的这些问题的答案，那么把你所有的时间花在调试器中并不是解决方案，而是问题的一部分。

在点击"发布你的答案"之前，我在谷歌上快速检查了这个准确的短语，结果发现我不是唯一持有这个观点或使用这个短语的人。我在Fog Creek软件论坛上对这个问题进行了长时间的讨论，其中引用了包括Linus Torvalds在内的各种灯具作为著名的支持者。

写大量的规范是徒劳的。编写正确的程序是相当困难的，但是编译器、调试程序、单元测试、测试人员等使检测和消除大多数错误成为可能。另一方面，当您使用类似于程序(即伪代码、UML)的类似详细级别编写规范时，您主要是自己编写的。如果你有一个能帮助你正确理解语法的工具，那你就应该庆幸自己。

广泛的规范很可能是错误百出的。作者在第一次尝试时就获得了正确的机会，这与类似的大型程序在没有经过测试的情况下无bug的机会差不多。同行评审消除了一些错误，就像代码评审一样。

大多数"用户友好"的第四代语言(包括SQL)都是一文不值的高估垃圾，这些垃圾本不应该被普遍使用。

4GL通常有一个冗长而不明确的语法。尽管4GL应该允许"非技术人员"编写程序，但您仍然需要"技术人员"编写和维护程序。

一般来说，4GL程序比更难写、更难读、更难优化。

应尽量避免使用4GL。

不是很有争议，但…Ajax在这个词出现之前就已经出现了，每个人都需要"放手"。人们用它来做各种各样的事情。但是没有人真正关心它。

突然，砰！有人创造了这个词，所有人都加入了Ajax的行列。突然之间，人们就成了Ajax的专家，就好像动态加载数据的专家以前并不存在一样。我认为这是导致互联网遭受残酷破坏的最大因素之一。以及"Web 2.0"。

默认情况下，数组应基于1而不是0。这并不一定是系统实现语言的情况，但是像Java这样的语言吞咽了比它们应该更多的C奇异性。元素1"应该是第一个元素，而不是第二个元素，以避免混淆。

计算机科学不是软件开发。毕竟，你不会雇佣只学物理的工程师。

尽可能多地学习数学。你不会使用它的大部分，但你需要能够这样想才能擅长软件。

目前标准化的最好的编程语言是通用的Lisp，即使它是冗长的，并且有零基数组。这在很大程度上是由于被设计成写计算，而不是作为冯·诺依曼机器的抽象。

至少90%对编程语言的比较性批评可以归结为"语言A有特性C，我不知道如何做C或语言B中的等价物，所以语言A更好。"

"最佳实践"是我见过的最令人印象深刻的拼写"平庸"的方法。

评论不好

每当代码需要注释来解释它在做什么时，代码就太复杂了。我总是尝试编写一些不需要太多注释就能解释的代码。

我可以不受封闭的生活。

现在看来，每个人和他们的母亲都希望用一种语言来表达封闭，因为这是自切片面包以来最伟大的发明。我认为这只是另一个炒作。

手动停止程序是发现性能问题的一种有效、经验证的方法。

可信吗？不是大多数。是真的吗？当然。

程序员的判断能力远远超过必要的。

在这些岗位上见证所有被认为是"邪恶"或"恐怖"的事情。

程序员对数据结构很满意。

见证所有关于类、继承、私有与公共、内存管理等的讨论，以及如何分析需求。

程序员需要与客户交谈

一些程序员认为他们不需要和客户交谈。对于你的公司来说，这是一个非常好的写作方式，没有人能弄清楚它是为了什么，或者它是如何被使用的。

你不能期望产品经理和业务分析师做出所有的决定。事实上，程序员应该在创建模块或特性的1000个(通常是很小的)决策中做出990个，否则产品将永远不会发布！所以要确保你的决定被告知。了解你的客户，与他们合作，观察他们使用你的软件。

如果你打算写最好的代码，你希望人们使用它。对你的用户群感兴趣，向那些在那里的"愚蠢的白痴"学习。别害怕，他们会爱你的。

如果它不值得测试，就不值得构建

下骆驼壳是愚蠢和不做作的。

使用较低的camelcase使名称/标识符(从这一点上使用的名称)看起来像是由两部分组成的东西。然而，上面的骆驼壳清楚地表明，所有的词都属于同一个词。

匈牙利符号不同…因为名字的第一部分是一个类型指示符，所以它与名字的其余部分有独立的含义。

有些人可能会争辩说，较低的camelcase应该用于函数/过程，特别是类内部。这在Java和面向对象的PHP中很流行。但是，没有理由这样做来表明它们是类方法，因为通过访问它们的方式，可以更清楚地看到它们只是类方法。

一些代码示例：

上面的camelcase对于类名和其他静态名称很有用。所有非静态内容都应通过访问方式识别，而不是通过名称格式识别！！)

这是我的同种代码示例，其中名称行为由除名称之外的其他事物表示…(另外，我更喜欢用下划线来分隔名称中的单词)。

因此，我的完全obcamelcase的主观意见。