并不是所有东西都需要封装到自己的方法中。有时候让一个方法做不止一件事是可以的。

要成为一名程序员，你必须会打字。

这在那些不知道如何打字，但坚持认为他们可以像任何打字员一样用两根手指搜索和啄的人之间存在争议，或者他们真的不需要花那么多时间打字，或者智能感知减轻了打字的需要……

我从来没有遇到过一个做知道如何打字的人，但坚持认为打字没什么区别。

参见:编程最肮脏的小秘密

每个开发人员都应该花几个星期，甚至几个月的时间来开发基于纸张的系统。他们也应该被迫使用他们的系统。

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

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

我们开发的系统并不是由一群训练有素的自动机控制的;真实的人使用它们，真实的人由经理培训，经理也是真实的人，没有太多的时间浪费在培训他们如何跳过你的圈子。

事实上，关于我的第二点:

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

“谷歌一下”是可以的!

是的，我知道这冒犯了一些人，他们多年的密集记忆和/或辉煌的编程书籍开始在一种任何人都可以在几秒钟内访问的资源中倒下，但你不应该反对使用它的人。

我经常听到有人用谷歌搜索问题的答案，但这确实毫无意义。首先，必须承认每个人都需要参考资料。你不是什么都知道，你需要去查资料。我承认，你从哪里得到的信息真的重要吗?你是在书上查到的，还是在谷歌上查到的，还是从你幻觉中的会说话的青蛙那里听到的，这有关系吗?不。正确的答案就是正确的答案。

重要的是你理解这些材料，将其作为成功编程解决方案的手段，并且客户/雇主对结果感到满意。

(虽然如果你是从幻觉中会说话的青蛙那里得到答案，你可能还是应该得到一些帮助)

如果你知道如何编程，你就不适合在表单上放置按钮

这有足够的争议吗?；）

不管我们多么努力，我们几乎不可能对53岁的Doris产生适当的同情，她必须使用我们的订单输入软件。我们根本无法理解她想象的计算机内部正在发生的事情的心理模型，因为我们不需要想象:我们知道正在发生什么，或者有一个非常好的想法。

交互设计应该由非程序员来完成。当然，这永远不会发生。相反，我对此很高兴;我喜欢UI设计，尽管内心深处我知道我并不适合它。

欲了解更多信息，请阅读该书收容所里的人在管理。请注意，这本书让我心烦意乱，很无礼;如果你是一个关心用户体验的开发人员，这是一篇很难读懂的文章。

不要在数据库中使用stored proc。

它们最初的优点——安全性、抽象性、单一连接——都可以在集成了许多其他优点的orm的中间层中实现。

这无疑是有争议的。每次我提起这件事，人们就把我撕成碎片。

QA应该比开发人员更了解代码(间接地)。QA通过发现开发人员不希望发生的事情而获得报酬，他们经常这样做。(顺便说一句，我是一名非常看重优秀QA人员的开发者。很少)。

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

我认为即使是最聪明和最有才华的人也永远不会成为真正优秀的程序员，除非他们不只是把编程当成一份工作。这意味着他们在业余时间做一些小项目，或者只是在业余时间摆弄各种不同的语言和想法。

(注意:我并不是说优秀的程序员除了编程什么都不做，而是说他们比朝九晚五的编程做得更多)

异常被认为是有害的。

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

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

这有争议吗?

编辑(澄清一下):我认为大多数软件架构师都是出色的业务分析师(与客户交谈，编写需求，测试等)，我只是认为他们在设计软件方面没有一席之地，无论是高级的还是其他的。

尽管我完全支持测试驱动开发(TDD)，但我认为在开发人员开始对问题的解决方案进行原型化的整个开发周期之前，还有一个至关重要的步骤。

我们经常陷入试图遵循我们的TDD实践来寻找一个可能被误导的解决方案，因为我们对这个领域不够了解。简单的原型通常可以阐明这些问题。

原型是很好的，因为与首先编写测试相比(有时)，您可以快速地浏览和丢弃更多的代码。然后，您可以开始开发过程，在空白的石板，但更好的理解。

“Java糟透了” -是的，我知道不是所有人都这么认为:)

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

探员

两行代码太多了。

如果一个方法有第二行代码，它就是代码气味。重构。

类应该适合屏幕。

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

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

在Python的方法声明中显式的self是糟糕的设计选择。

方法调用有语法糖，但声明没有。这是一个有漏洞的抽象(故意的!)，会导致令人讨厌的错误，包括运行时错误，在报告的参数数量中明显少了一个错误。

原始数据类型是不成熟的优化。

有些语言只使用一种数据类型，即标量，它们做得很好。其他语言就没有这么幸运了。开发人员只是把“int”和“double”扔进去，因为他们必须写一些东西。

重要的不是数据类型有多大，而是数据的用途。如果你有一个月中的某一天变量，它是有符号还是无符号，或者它是char、short、int、long、long long、float、double或long double都不太重要。重要的是它是一个月中的一天，而不是一个月，或者一周中的一天，或者其他什么。请看Joel的专栏，让错误看起来是错误的;匈牙利符号如最初提议的那样是个好主意。在实际使用中，它基本上是无用的，因为它说的是错误的事情。

我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员，我们需要违反MVC设计模式的规则，以使网站运行得更快。这对开发人员来说是很难接受的，他们通常不愿意牺牲设计良好的代码。但是性能是我们构建web应用程序的首要任务，所以有时我们不得不在框架上做出让步。

例如，视图层永远不应该直接与数据库对话，对吗?但是，如果你要生成大型报告，应用程序将使用大量内存来通过模型层和控制器层传递数据。如果你有一个支持游标的数据库，它可以让应用程序更快地直接从视图层访问数据库。

性能胜过开发标准，这是我有争议的观点。

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

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

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

返回代码的使用很简单，可以很容易地系统地验证覆盖范围，如果处理得当，就会迫使开发人员生成有用的错误消息，而不是太常见的堆栈转储和模糊的I/O异常，即使对最聪明的最终用户来说，这些异常也“异常”毫无意义。

--

我最后的反对意见是使用垃圾收集语言。不要误会我的意思。在某些情况下，我喜欢它们，但在服务器/MC系统中，它们在我看来没有位置。

GC并不是绝对正确的——即使是设计得非常好的GC算法也可能基于依赖关系图中不明显的循环引用而在对象上停留太长时间，甚至永远停留。

遵循一些简单模式并使用内存计算工具的非GC系统不会有这个问题，但在设计和测试方面需要比GC环境做更多的工作。这里的权衡是，在非GC测试期间，内存泄漏非常容易发现，而找到与GC相关的问题条件则要困难得多。

内存是便宜的，但当你泄露昂贵的对象，如事务句柄、同步对象、套接字连接……在我的环境中，如果不对软件描述进行重大的基本更改，那么您可以坐下来让语言为您操心，这种想法是不可想象的。

PHP文件中过多的HTML:有时是必要的

PHP文件中Javascript过多:触发猛禽攻击

虽然我很难弄清楚你在回声ing和?><之间的所有切换;php编写HTML(毕竟，php只是HTML的处理器)，一行一行的javascript添加进来，使它完全无法维护。

人们必须明白这一点:它们是两种独立的编程语言。选择一种作为你的主要语言。然后继续寻找一种快速、干净、易于维护的方法，使你的主要语言包括第二语言。

你之所以总是在PHP、Javascript和HTML之间切换，是因为你对这三种语言都不在行。

好吧，也许这并不是很有争议。我的印象是，这是一个普遍的沮丧发泄话题:)

观点:开发者应该测试自己的代码

我曾经见过太多的垃圾交付给测试，但实际上并没有修复问题中的bug，导致了沟通开销，并助长了不负责任的实践。

Web应用程序糟透了

我的网速很慢。我使用几乎所有不是谷歌的网站的经验至少是令人沮丧的。为什么现在没人写桌面应用了?哦，我明白了。没有人愿意学习操作系统是如何工作的。至少，不是Windows。上次你不得不处理WM_PAINT时，你的头爆炸了。创建一个工作线程来执行一个长时间的任务(我的意思是，用Windows的方式来做)完全超出了你的能力。回调是什么鬼?哦，天哪!

垃圾收集糟透了

不，实际上没有。但这让程序员们非常糟糕。在大学里，他们教我们的第一门语言是Visual Basic(最初的语言)。在那之后，还有另一门课，老师教我们c++。但损害已经造成。实际上没有人知道如何使用这个深奥的关键字delete。在测试我们的程序之后，我们要么得到无效的地址异常，要么得到内存泄漏。有时候，我们两者都有。在我1%会编程的教员中，只有一个人能自己管理记忆(至少，他假装如此)，而他却在写这篇咆哮。其余的人用VB编写程序。NET，根据定义，它是一种糟糕的语言。

动态类型糟糕透了

当然，除非您正在使用汇编程序(这是一种值得称赞的动态类型)。我的意思是动态解释语言带来的开销让它们很糟糕。不要用不同的工具适用于不同的工作。C语言是几乎所有事情的正确语言(它快速、强大、可移植)，当它不是(它不够快)时，总有内联汇编。

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

在彻底考虑一个问题之前，永远不要在这个问题上做出决定。任何编程标准都不能证明以糟糕的方式处理问题是正确的。如果标准要求编写一个类，但经过仔细考虑，您认为静态方法更合适，则始终使用静态方法。你自己的谨慎总是比编写标准的人最具前瞻性的想法更好。如果你在一个团队中工作，标准是很好的，但规则就是要被打破的(当然是有品位的)。

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

它具有委员会设计的所有特征——它不能很好地完成任何给定的工作，而且某些工作(如面向对象)做得很糟糕。它有一种“厨房水槽”的绝望，不会消失。

它是学习编程的可怕的“第一语言”。你(从语言中)得不到优雅，得不到帮助。取而代之的是陷阱和雷区(内存管理、模板等)。

它不是一种学习面向对象概念的好语言。它表现为“带有类包装器的C”，而不是一种合适的OO语言。

我可以继续讲下去，但现在就讲到这里。我从来不喜欢用c++编程，虽然我是在FORTRAN上“磨砺”的，但我完全喜欢用C编程。我仍然认为C是最伟大的“经典”语言之一。在我看来，c++肯定不是这样的。

欢呼,

- r

编辑:回复关于c++教学的评论。你可以用两种方式教授c++——要么把它作为C“类固醇”来教授(从变量、条件、循环等开始)，要么把它作为纯粹的“面向对象”语言来教授(从类、方法等开始)。你可以找到使用其中一种或另一种方法的教学文本。我更喜欢后一种方法(面向对象优先)，因为它确实强调了c++作为面向对象语言的功能(这是c++最初的设计重点)。如果你想“像C一样”教c++，那么我认为你应该教C，而不是c++。

但就我的经验而言，c++作为第一语言的问题在于，这门语言太大了，无法在一个学期内教授，而且大多数“介绍”文本试图涵盖所有内容。在“第一语言”课程中涵盖所有主题是不可能的。在我看来，你至少要把它分成两个学期，然后它就不再是“第一语言”了。

我确实教c++，但只是作为一种“新语言”——也就是说，你必须精通一些先前的“纯”语言(不是脚本或宏)，然后才能注册这门课程。在我看来，c++是一种很好的“第二语言”。

- r

另一个编辑:(对康拉德)

我完全不同意c++“在各方面都优于”C。我花了数年时间为微控制器和其他嵌入式应用程序编写C程序。用于这些设备的C编译器是高度优化的，通常生成的代码与手工编写的汇编器一样好。当你转向c++时，你会得到编译器强加给你的巨大开销，以管理你可能不会使用的语言特性。在嵌入式应用程序中，添加类之类的东西收效甚微。你需要的是紧凑、干净的代码。你可以用c++来写，但实际上你只是在写C，而且C编译器在这些应用程序中更加优化。

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

- r

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

有很多糟糕的教学。

当Joel说大脑中有一部分是用来理解指针的，而有些人生来就没有指针时，我们开发人员就会沾沾自喜。我们许多人在这里讨论的话题都是深奥的，但有时这只是因为我们让他们如此。

最好的代码通常不是你写的。作为程序员，我们希望通过编写一些很酷的方法来解决每个问题。任何时候，我们都能在解决问题的同时满足用户80%的需求，而无需引入更多代码进行维护和测试，我们已经提供了更多的价值。

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

c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#

库克的格言随意收集……

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

• 最难学的操作系统是你的第二个操作系统——特别是如果你的第一个操作系统是IBM大型机的话。

一旦你学会了几种看似不同的语言， 你终于意识到所有的编程 语言是一样的-只是语法上的细微差别 虽然一个人不学组装也可以很有生产力，很有市场，
调试器是那些真正不懂的程序员的最后避难所 他们首先在做什么。

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

• 低级别的系统编程比应用程序编程简单得多。

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

• 首先编写用户指南!

• 政策和程序是为那些缺乏主动性的人制定的。

• (承包商信条): 告诉他们需要什么。 他们要什么就给他们什么。

. Make sure the check clear .
. 如果你不觉得编程有趣，那就放弃它或接受它，尽管你可能会做得很好 生活在这样的生活中，你永远不会超过平均水平

• 就像那些老家伙必须学习。net方法名一样， 你得学会如何去图书馆。但是这里没有什么新东西 程序员的生活就是不断适应不同的环境， 你身上挂的工具越多，你就越多才多艺，越有销路 你可以在开始的时候用一些小代码块来尝试一些想法， 但是，一般来说，一个人不会认真地开始编码，直到你知道整个程序或 app会被布局，你知道整个事情会完全像 广告。对于大多数至少具有一定复杂程度的项目， 我通常会把60%到70%的时间都花在构思上 理解编程与语言无关，而与算法有关。 这些年来，人们想出了所有那些带有令人难忘的首字母缩写的漂亮的小玩意儿 只是剥实现猫皮的不同方式。当你剥去所有的 OOPiness，放射学，开发方法论37和最佳实践42，你仍然需要处理 基本构建块:

  • 作业
  • 条件
  • 迭代
  • 控制流
  • I / O
  李< / ul > < / >
  一旦你能真正把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型
  初级程序员使用小块代码。随着经验的积累， 它们处理越来越大的代码块 当他们获得更多的经验时，他们会处理小块的代码

根据我得到的反馈，我最具争议的观点，显然是程序员并不总是读他们声称读过的书。这紧随其后的是我的观点，受过正规教育的程序员比自学成才的程序员更好(但不一定比自学成才的一个不同的程序员更好)。

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

嗯…OP说有争议!

• Xah Lee:实际上有一些非常值得注意和合理的观点，如果你能过滤掉所有的谩骂，理性地评估语句，而不同意(或不同意)仅仅基于语句背后的个性。我的许多“有争议的”观点都得到了他和其他臭名昭著的“喷子”的回应，他们经常批评我使用的语言或工具。

• [Documentation Generators](http://en.wikipedia.or /wiki/Comparison_of_documentation_generators):…创造者发明了一些专门用于文档源代码的定制语法(包括但不限于JavaDoc)，这些语法完全是多余的，是浪费时间的，因为:

  • 1)最应该使用它们的人却没有充分利用它们;而且
  • 2)所有这些小型文档语言所有的都可以很容易地被YAML取代
  李< / ul > < / >

继承是邪恶的，应该被摈弃。

事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。

一旦发现缺陷就改正。不仅仅是“严重程度1”的缺陷;所有缺陷。

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

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

计算机科学学位不会——也不应该——教你成为一名程序员。

编程是一门手艺，计算机科学是一个研究领域。你可以是一个伟大的程序员，也可以是一个糟糕的计算机科学家，也可以是一个伟大的计算机科学家，也可以是一个糟糕的程序员。了解其中的区别是很重要的。

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

Web服务绝对很糟糕，也不是未来的发展方向。他们的效率低得可笑，而且他们不能保证订单交货。Web服务绝不应该在同时编写客户端和服务器的系统中使用。它们对于米老鼠混搭类型的应用程序非常有用。它们绝对不应该用于任何类型的面向连接的通信。

这种立场让我和同事们进行了一些非常热烈的讨论，因为web服务是一个非常热门的话题。任何强制使用web服务的项目都是注定要失败的，因为它显然已经从管理层那里得到了荒谬的要求。

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

面向对象编程的主要问题是完全缺乏一个每个人都能认同的严格定义。这很容易导致实现中存在逻辑漏洞，或者像Java这样的语言坚持这种关于OOP含义的奇怪的宗教教条，同时迫使程序员做所有这些扭曲和“设计模式”，只是为了绕过特定OOP系统的限制。

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

然后，由于没有人知道OOP的真正含义，我们浪费了大量的时间在争论语言X或Y是否“真正的面向对象”，什么奇怪的语言特性对于一种语言被认为是“真正的面向对象”是绝对“必要的”。

与其要求这种语言或那种语言是“真正的面向对象的”，我们应该看看实验显示了什么语言特性，以提高生产力，而不是试图强迫它成为某种想象中的理想语言，或者确实强迫我们的程序符合“真正面向对象的程序”的一些柏拉图式的理想。

与其坚持我们的程序符合“真正面向对象”的柏拉图式理想，不如我们专注于坚持良好的工程原则，使我们的代码易于阅读和理解，并使用一种语言的高效和有用的特性，而不管它们是否足够“面向对象”。

UML图被高度高估了

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

您不应该停留在您发现的编写“有效”代码的第一种方法上。

我真的不认为这应该引起争议，但事实确实如此。人们从代码的其他地方，从网上，或者从一些旧的1999年的“自学高级sqljava# BeansServer 3.14159分钟”的书中看到示例，他们认为自己知道一些东西，并将其复制到自己的代码中。他们不会遍历示例来找出每一行是做什么的。他们不会考虑程序的设计，也不会考虑是否有更有组织或更自然的方式来做同样的事情。他们不会试图让自己的技能保持最新，以了解他们所使用的思想和方法在上个千年的最后一年已经过时了。他们似乎没有经验来了解他们所复制的东西多年来已经为程序员带来了特定的可怕的维护负担，而这些负担可以通过更多的思考来避免。

事实上，他们似乎甚至没有意识到做一件事可能有不止一种方法。

我来自Perl世界，那里有一个口号是“有不止一种方法来做它”。粗略地看了一下Perl的人认为它“只能写”或“不可读”，这主要是因为他们看到了由具有我上面描述的心态的人编写的蹩脚代码。这些人根本不考虑设计、可维护性、组织、减少代码重复、耦合、内聚、封装等问题。他们写的是垃圾。这些人用各种语言编程，而且很容易学习语言，有很多做事的方法，这给了他们足够的绳子和枪来射击和上吊自己。同时进行。

但是，如果你在Perl世界里停留得更久，而不是粗略地看一眼，并观察社区里的长期工作者在做什么，你会看到一件了不起的事情:优秀的Perl程序员花了一些时间来寻找最好的方法来做某事。当他们命名一个新模块时，他们会四处征求建议，并从人们那里得到他们的想法。他们将自己的代码交给别人查看、批评和修改。如果他们不得不做一些讨厌的事情，他们会以尽可能小的方式将其封装在一个模块中，以便以更有组织的方式使用。同一理念的多个实现可能会存在一段时间，但它们会争夺思想份额和市场份额，它们的竞争方式是努力做到最好，其中很大一部分是让自己易于维护。真正优秀的Perl程序员似乎对他们正在做的事情和寻找最好的方法来做事情，而不是仅仅抓住他们大脑中掠过的第一个想法。

如今，我主要在Java世界中编程。我见过一些非常好的Java代码，但我也见过很多垃圾代码，而且我还看到了更多我在开头描述的心态:人们选择了第一个看起来可以工作的丑陋代码块，而不理解它，也不考虑是否有更好的方法。

你会在每种语言中看到这两种心态。我并不是要专门抨击Java。(事实上，在某些方面我真的很喜欢……也许这才是我真正有争议的观点!)但是我开始相信，每个程序员都需要在tmtowtdi风格的语言上花上几年的时间，因为尽管传统观点认为这会导致混乱和糟糕的代码，但它实际上似乎培养了一些人，他们理解您需要考虑您所做的事情的影响，而不是相信您的语言被设计成可以让您毫不费力地做正确的事情。

我确实认为你可能会在另一个方向上走得太远:例如，完美主义完全忽略了你的真正需求和目标(通常是你的业务的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，除非学会投入一些高于平均水平的努力来思考寻找最好的(或至少是最好的一种)方法来编码他们正在做的事情。

Variable_Names_With_Bloody_Underscores

或者更糟

CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES

应该被全局删除…与偏见!CamelCapsAreJustFine。 (不能承受全局常量)

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

任何不支持指针的语言都名不副实

-全局常量应该全部大写，带“_”分隔符。 我实际上同意这一点，因为它是如此BLOODY_OBVIOUS

-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。

我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。

• C函数名

  • 在c++项目中应该有很少的C函数。
  • 对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。
  李< / ul > < / >

  的理由

  * It makes C functions very different from any C++ related names.
  

  例子

  < p > int some_bloody_function () ｛ } < / p >

  这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。

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

  这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。

  我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!

需求分析、规格说明、设计和文档几乎永远不适合“模板”。你100%的时间更好的从一个空白的文档并开始类型的观点“我将解释这以这样一种方式,如果我死了,别人阅读本文档,他们会知道一切,我知道,现在看到和理解”然后组织从那里,让部分标题等自然发展和适合你指定的任务,而不是局限于一些企业或学校的文档应该是什么样子。如果你必须做一个图表，而不是使用别人的正式的和难以理解的系统，你通常最好只是画一个有意义的图表，带有一个清晰的图例，它实际上指定了你试图指定的系统，并传达了另一端的开发人员(通常是你，几年后)需要接收的信息。

[如果有必要，一旦您编写了真正的文档，您通常可以把它塞进组织强加给您的任何模板中。不过，你可能会发现自己不得不添加章节标题和重复的材料。

只有当您有大量本质上非常相似，只是在细节上有所不同的任务时，这类文档的模板才有意义。“编写一个程序，允许通过这个调制解调器库进行一次性远程登录访问，使用C-Kermit驱动终端连接连接”，“生成容量使用的历史趋势和预测报告”，“使用这个库使所有报告都能够传真”，“修复用于2000年问题的代码”，和“将数据库触发器添加到此表，以填充由第三方供应商提供给我们的软件产品”不都可以由相同的模板描述，无论人们可能会怎么想。在此声明一下，我的大学课程试图教给我和我的同学的需求和设计图表技术不能用来指定一个简单的计算器程序(每个人都知道)。

一张图片不是胜过千言万语。

有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的，是许多懒惰的经理的可悲借口，他们不想仔细阅读创建的报告和文档，说“我需要你在图表中展示给我看”。

我妻子学的是语言学专业，她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍，它们通常不能像正确的文本那样传达那么多的信息，它们根本不能取代真正的交流。

特别是，如果线条未被标记且无法解释，并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分)，那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系，有时表示动作，有时表示时间的流逝，你就真的完蛋了。

每个优秀的程序员都知道你使用的工具适合手头的工作，对吗?并不是所有的系统都最好用图片来说明和记录。可以自动转换为可证明正确的可执行代码或任何东西的图形规范语言是壮观的思想，如果这样的东西存在的话。在适当的时候使用它们，而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。

注意:表格可能值其重量的黄金。但是表格和图片不是一回事。同样，一篇精心设计的短散文段落可能更适合手头的工作。

XML被高度高估了

我认为太多人在使用他们的大脑之前就开始了XML的潮流… XML对于web来说是很棒的，因为它就是为它设计的。否则，我认为一些问题定义和设计的想法应该优先于任何使用它的决定。< / p >

我的5美分

“好的编码员代码和伟大的编码员重用它”这是现在发生的事情，但“好编码员”是唯一的一个谁享受代码。 和“伟大的程序员”只是为了找出其中的漏洞，因为他们没有时间思考和编码。但是他们有时间找到代码中的错误

所以不要批评!!!!!!!!

按照你的方式创建自己的代码。

代码的重用与其“可重用性”成反比。因为“可重用的”代码更复杂，而快速的hack更容易理解，所以它们被重用。

软件故障应该使系统崩溃，以便对其进行检查和修复。试图处理失败条件的软件通常比崩溃更糟糕。也就是说，是在崩溃后重新设置系统更好，还是应该因为失败处理程序有一个错误而无限期地挂起系统?

做莫特没关系

不是每个人都是“摇滚明星”程序员;我们中的一些人这样做是因为这是一个好的生活，我们不关心所有最新的时尚和趋势;我们只想做好本职工作。

Java并不是最好的东西。仅仅因为它带有“企业”标签并不意味着它就好。也不会让它变快。也不是所有问题的答案。

另外，ROR并不是博客圈所吹嘘的那样。

当我在做的时候，OOP并不总是好的。事实上，我认为它通常是不好的。

观点:大多数代码都很糟糕，因为这是程序员想要的。

间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。

如果我们让我们的行业朝着这个方向发展，最终就意味着让每个程序员都可以去开发任何他们想要的极具创造性的疯狂内容。当然，对于任何规模较大的项目，试图将数十个不相关、无结构、无计划的部分组合成一个最终一致的部分，显然是行不通的。这不是猜测，也不是估计，这是我们今天所面临的行业现状。您有多少次在主要程序中看到功能的子部分与其余代码完全不一致?它现在是如此普遍，这是一个奇迹，任何人造成使用任何这些混乱。

复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)

但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。

我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?

保罗。

聪明的程序员很危险

我花了更多的时间试图修复“聪明”程序员编写的代码。我宁愿有一个优秀的程序员，而不是一个特别聪明的程序员，他想通过编写只有他(或她)才能解释的代码来证明自己有多聪明。

如果开发人员写不出清晰、简洁、语法正确的注释，那么他们就应该回去补习英语。

我们有开发人员和(可怕的)架构师不能连贯地编写。当他们的文件被审查时，他们会说“哦，不要担心语法错误或拼写错误——那不重要”。然后他们想知道为什么他们复杂的垃圾文档变成了复杂的bug代码。

我告诉我所指导的实习生，如果你不能口头或书面表达你的伟大想法，那就不如没有它们。

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

请注意，当我说“足够好”时，我的意思是“足够好”，而不是碰巧有用的垃圾。但话又说回来，当你时间紧迫的时候，“一些碰巧有用的垃圾”可能被认为是“足够好的”。

大多数咨询程序员都很差劲和不应该被允许写生产代码。

恕我冒昧，大概60%或更多

意见:不应该有任何编译器警告，只有错误。或者，以不同的方式表述您应该始终使用-Werror编译代码。

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

大多数专业程序员都很糟糕

我遇到过太多为了谋生而做这份工作的人，他们对自己所做的事情很糟糕。蹩脚的代码，糟糕的沟通技巧，对新技术毫无兴趣。太多太多了……

大多数“用户友好”的第四代语言(包括SQL)都是毫无价值的、被高估的垃圾，不应该被广泛使用。

4gl通常有一个冗长和模糊的语法。尽管4gl应该允许“非技术人员”编写程序，但你仍然需要“技术人员”来编写和维护它们。

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

应该尽量避免使用4gl。

不要注释你的代码

注释不是代码，因此当事情发生变化时，不改变解释代码的注释是很容易的。相反，我更喜欢将代码中的垃圾重构到不需要注释的程度。一个例子:

if(data == null)  // First time on the page

:

bool firstTimeOnPage = data == null;
if(firstTimeOnPage)

我唯一一次真正的评论是当它是一个TODO或解释为什么

Widget.GetData(); // only way to grab data, TODO: extract interface or wrapper

如果以后可以节省3倍的时间，那就只写抽象。

有时我看到人们写出这些疯狂的抽象概念，我就会想:“为什么?”

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

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

一个真正糟糕的程序员几乎可以用任何语言写出糟糕的代码。

我有争议的观点?Java并不糟糕，但Java API很糟糕。为什么java库坚持让简单的任务变得困难?为什么他们不修复api，而是创建框架来帮助管理样板代码?这种观点适用于任何需要10行或更多代码才能从文件中读取一行的语言。

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

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

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

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

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

快速记住成千上万的参数列表、拼写和返回值(更不用说类结构和类似复杂的组织模式)是一项计算机擅长而人(相对而言)不擅长的任务。我全心全意地相信放慢速度，避免小工具/特性崇拜是提高效率和避免bug的好方法，但如果你可以在源代码或文档中花费零时间，那么花30秒不必要的时间来寻找没有任何好处……特别是当你只需要一个拼写(这种情况比我们愿意承认的情况更常见)。

当然，如果没有为您的语言提供这种功能的编辑器，或者任务简单到足以在加载更重的编辑器所需的时间内完成，那么没有人会告诉您Eclipse和90个插件是正确的工具。但是请不要告诉我，像1999年那样使用H-J-K-L的能力真的比每次需要方法签名时按escape键节省了更多时间……即使你觉得这样做不那么“黑客”了。

想法吗?

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

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

分页从来不是用户想要的

如果你开始讨论在哪里进行分页，在数据库中，在业务逻辑中，在客户端上，等等，那么你就问错了问题。如果你的应用程序返回的数据比用户需要的多，想办法让用户根据真实的标准缩小他们需要的数据，而不是任意大小的数据块。如果用户确实想要所有这些结果，那么给他们所有的结果。你一次回馈20个结果是在帮助谁?服务器吗?这比用户更重要吗?

[编辑:基于评论的澄清]

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

我更喜欢以下选择之一:

1. 请允许我搜索答案(这是一种根据实际标准缩小我需要的范围的方法)。

2. 允许我看到所有的答案，这样我就可以使用浏览器的“查找”选项(给我所有的结果)。

如果我只是想找到以前读过的答案，但再也找不到了，也可以这样做。我不知道它是什么时候发布的，也不知道它有多少选票，所以排序选项没有帮助。即使我找到了，我仍然需要玩猜谜游戏来找到正确的结果页面。事实上，答案是分页的，我可以直接点击进入十几个页面中的一个一点帮助都没有吗。

我认为使用goto语句是很好的，如果你以一种理智的方式使用它们(以及一种理智的编程语言)。它们通常可以使您的代码更容易阅读，并且不会强迫您使用一些扭曲的逻辑来完成一件简单的事情。

尽可能在任何地方使用类型推断。

编辑:

这是我几个月前写的一篇关于我为什么有这种感觉的博客文章的链接。

http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx

c++是一门很好的语言

一两个星期前，我说c++不是一种很好的语言，在另一个问题上我几乎被私刑了。现在我试着反过来说。；）

不，认真地说，我当时想说的是，c++有很多缺陷，现在我还会再试一次。这一点很难否认。它是如此的复杂，以至于学好它实际上是一件你可以奉献一生的事情。它使许多常见的任务变得不必要的困难，允许用户一头扎进未定义的行为和不可移植的代码的海洋，而编译器没有给出警告。

但它并不是许多人试图创造的那种无用、破旧、过时、令人讨厌的语言。它不应该被掩盖和忽视。没有它，世界不会变得更好。它有一些独特的优势，不幸的是，隐藏在古怪的语法，遗留的麻烦，尤其是糟糕的c++老师背后。但是他们就在那里。

c++有许多我在用c#或其他“现代”语言编程时非常怀念的特性。其中有很多c#和其他现代语言可以学习的地方。

它并没有盲目地专注于OOP，而是探索并开创了泛型编程。它允许惊人地表达编译时元编程，产生极其高效、健壮的而且干净代码。在c#出现LINQ或lambda表达式之前，它从函数式编程中吸取了近十年的经验教训。

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

变量的确定性销毁允许RAII，这是一个非常强大的小技巧，使try/finally块和c#的using块变得多余。

虽然有些人指责它是“由委员会设计的”，但我会说，是的，它是，在这种情况下，这实际上并不是一件坏事。看看Java的类库。又有多少类被弃用了?有多少不应该使用?有多少是相互复制的功能?有多少设计糟糕?

c++的标准库要小得多，但总的来说，它的设计非常好，除了一两个小缺陷(例如vector<bool>)，它的设计仍然很好。当一个特性被添加到c++或其标准库中时，它会受到严格的审查。Java难道不能从中受益吗?. net也一样，尽管它更年轻，而且从一开始就设计得更好，但仍然积累了大量与现实不同步的类，或者从一开始就设计得很糟糕。

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

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

我不在乎你有多少年的工作经验，读过多少博客，参与过多少开源项目。一个资格证书(我建议超过3年)会让你接触到一种不同的思维方式，给你一个很好的基础。

仅仅因为你写了一些比计算机科学学士更好的代码，并不意味着你比他更好。你所拥有的，他可以在瞬间学会反之则不然。

拥有资格证书表明了你的承诺，你会超越经验，成为一名更好的开发人员。擅长自己的工作并且有资格的开发人员可能会非常令人生畏。

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

而且，一旦你有了资格，你就会慢慢停止和其他有资格的人比较(我的经验)。你意识到到最后一切都不重要了，只要你们能很好地合作。

始终仁慈地对待其他开发人员，无论其资格如何。

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

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

这真的只是用魔锤方法解决问题的一个具体例子，但它真的很痛苦。

代码越少越好!

如果用户说“就这样?”，而你的工作仍然是隐形的，那么你的工作就做对了。荣耀可以在其他地方找到。

开发人员都是不同的，应该被区别对待。

开发者不属于任何一个框框，也不应该被这样对待。解决问题的最佳语言或工具与开发人员的关系与被解决问题的细节关系一样大。

不断测试

您必须编写测试，并且必须首先编写它们。编写测试会改变编写代码的方式。它会让你思考你想要它实际做什么，然后再开始写一些东西，它能做所有事情，除了你想要它做的。

它也给你目标。看着你的测试变绿会让你有额外的信心，因为你完成了一些事情。

它还为您为边缘情况编写测试提供了基础。由于您一开始就针对测试编写代码，因此您的代码中可能有一些用于测试的钩子。

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

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

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

如果你被公共汽车撞了，被解雇了，被解雇了，或者离开了工作岗位，你的雇主应该能够在片刻的通知中取代你，下一个人可以接替你的角色，拿起你的代码，最多在一周内启动并运行。如果他或她不能做到这一点，那么你就失败了。

有趣的是，我发现有了这个目标，我对雇主来说更有价值了。我越努力成为可有可无的人，我对他们就越有价值。

其中一个我已经琢磨了很久了:

数据就是系统。

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

没有数据，过程/软件就没有什么价值。没有流程或软件，数据仍然有价值。

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

成功的软件/系统/过程似乎有一个敏锐的意识，如果不是狂热的正念，在任何给定的时刻数据在“哪里”。

开发人员应该能够在不获得任何人许可的情况下修改产品代码，只要他们记录了他们的更改并通知了适当的方。

未注释的代码是人类的祸害。

我认为注释对于代码是必要的。他们可视化地将其划分为逻辑部分，并在阅读代码时提供另一种表示方式。

文档注释是最低限度的，但是使用注释来分割较长的函数有助于编写新代码，并允许在返回现有代码时更快地分析。

硬编码很好!

真的，在许多情况下更有效，更容易维护!

对于C程序，只需将这些类型的值硬编码到头文件中，对于java程序，只需将这些值硬编码到静态类中等等。

当这些参数对你的程序行为有巨大的影响时，你真的想对每一个变化做一个回归测试，这似乎是硬编码值更自然。当东西存储在参数/属性文件中时，人们很容易认为“这不是一个程序变更，所以我不需要测试它”。

另一个好处是，它可以防止人们在参数/属性文件中混淆重要值，因为根本没有任何重要值!

在将代码合并到主线之前进行审批是一个糟糕的想法。它在开发人员中滋生了不安全感和懒惰，如果他们知道他们可能会搞砸几十个人，他们就会非常小心地对待他们所做的更改，他们会陷入一种不需要考虑他们可能影响的代码的所有可能客户端的感觉中。检查代码的人不太可能像编写代码的人那样思考它，所以它实际上可能导致检入的代码质量较差……不过，是的，它可能会遵循所有的风格指导方针，并得到很好的评论:)

递归最糟糕的地方就是递归。

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

他们有自己的目的。很多优秀的软件都是用它们开发出来的。但事实上，我们需要编写这些心理抽象的“配方”，关于你的代码如何工作/应该如何工作，这说明缺乏足够有表现力的编程语言来为我们处理这种抽象。

补救办法，我认为，在于允许你将越来越多的设计嵌入到代码中的语言，通过定义可能不存在或可能没有普遍适用性，但在你的代码不断处理的情况下真的确实有意义的语言结构。Scheme的人已经知道这一点很多年了，Scheme宏可能会让大多数猴子尿裤子。

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

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

更正:没有开发经验的员工不应该被允许管理开发人员。

生成的文档几乎总是毫无价值的。

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

实际上有两类人需要了解您的API:维护者，他们必须了解您的实现的细节，以便有效地完成工作;用户，他们需要高级的概述、示例和关于他们所访问的每个方法的效果的详细细节。

我从未遇到过在这两个方面都成功的生成文档。通常，当程序员为工具编写注释以提取和生成文档时，他们的目标是介于两者之间的某个地方——刚刚足够的实现细节让用户感到厌烦和困惑，但不足以显著帮助维护者，并且没有足够的概述对用户有任何真正的帮助。

作为维护者，我宁愿总是有干净、清晰的注释，不被你的自动文档工具要求的任何奇怪标记所混淆，告诉我为什么你用这种方式写了那个奇怪的switch语句，或者这个看起来多余的参数检查修复了什么错误，或者其他我需要知道的东西，让代码在我工作时保持干净和无错误。我希望这些信息就在代码中，与它所涉及的代码相邻，这样我就不必在你的网站上寻找适合阅读的状态。

作为一个用户，我宁愿总是有一个彻底的，组织良好的文档(一组网页将是理想的，但我满足于一个结构良好的文本文件，太)告诉我你的API是如何架构的，什么方法做什么，以及我如何可以完成我想要使用你的API做什么。我不想在内部看到你写了什么类来允许我做工作，或者它们在什么文件里。我当然不想下载你的源代码这样我就能弄清楚幕后到底发生了什么。如果你的文件足够好，我就不用了。

无论如何，这就是我的看法。

扩展方法是魔鬼的工作

每个人似乎都认为。net中的扩展方法是自切片面包以来最好的东西。赞美他们的开发者似乎越来越多，但我还是忍不住鄙视他们，除非有人能提出一个我还没听过的绝妙理由或例子，否则我永远也不会写出来。我最近遇到了这个线程，我必须说，阅读投票最高的扩展的例子让我感觉有点像呕吐(当然是比喻)。

主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。

恐怕我有不同意见，我发现事实上，它们毫无疑问地降低了可读性和oo性，因为它们的核心是一个谎言。如果你需要一个作用于对象的实用方法那就写一个作用于对象的实用方法别骗我。当我看到aString。SortMeBackwardsUsingKlingonSortOrder那么字符串应该有那个方法因为它告诉我关于字符串对象的东西而不是关于AnnoyingNerdReferences的东西。StringUtilities类。

LINQ是这样设计的，链式方法调用是必要的，以避免奇怪和不舒服的表达式，来自LINQ的扩展方法是可以理解的，但一般来说，链式方法调用降低了可读性，并导致我们在混乱的Perl竞赛中看到的那种代码。

因此，简而言之，扩展方法是邪恶的。摆脱撒旦的枷锁，致力于自由扩展代码。

不要太担心学习什么语言，使用业界重量级的语言，如c#或python。像Ruby这样的语言在卧室里很有趣，但在工作场合就没什么用了。像c#和Java这样的语言可以处理小到非常大的软件项目。如果有人不这么认为，那么你谈论的是脚本语言。期!

在开始一个项目之前，要考虑网络上有多少支持和代码示例。再次强调，选择像Ruby这样的语言，与Java相比，Ruby的代码样本在网络上非常少，这只会让你在遇到问题时更加痛苦。

当你的老板问你的代码写得怎么样的时候，你不能在论坛上发了一条消息就指望得到答复。你要说什么?“我在这个论坛上等着有人来帮我”

学习一门语言，并学好它。学习多种语言可能会带来技能和实践，但你甚至只能掌握所有语言。擅长其中一项。有一整本专门讲Java中的线程的书，仔细想想，它只是100多个命名空间中的一个。

精通一门或精通许多门。

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

在网页布局中使用表格

如果我正在开发一个需要压缩性能的大型站点，我可能会考虑这样做，但是没有什么比表更容易让我在浏览器上获得一致的外观了。我开发的大多数应用程序都是针对100-1000个用户，最多一次100个用户。额外膨胀的表无论如何都不会杀死我的服务器。

如果你有合适的工具，并花时间正确地编写，那么软件就可以没有错误。

意见:没有函数定义和返回类型会导致代码灵活且可读。

这种观点可能更适用于解释型语言，而不是编译型语言。需要一个返回类型和一个函数参数列表，这对于智能感知来自动记录你的代码是很好的，但它们也是限制。

不要误解我的意思，我不是说扔掉返回类型，或者参数列表。他们有自己的位置。在90%的情况下，它们是利大于弊的。

在某些时候和场合，这是有用的。

编码不是打字

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

如果你长时间敲击键盘，那你一定做错了什么。

推论:每天写的代码行数并不是一个程序员生产力的线性衡量标准，因为一天写100行的程序员很可能比一天写20行的程序员更好，但写5000行的程序员肯定是坏程序员

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

通常只是一些经理提供“需求”。

“邪恶”这个词在Stackoverflow和类似论坛上是一个被滥用和过度使用的词。

使用它的人想象力太少。

开发团队应该更多地按照技术/架构层而不是业务功能来划分。

我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储procs，匹配数据访问代码，实现业务逻辑和web服务方法，以及web页面接口。

你猜怎么着?每个人都有自己的用自己的方式做事!每个人都斗争学习ASP。NET AJAX和Telerik或Infragistic套件，企业库或其他生产力和数据层和持久性框架，面向方面的框架，日志和缓存应用程序块，DB2或Oracle的特性。你猜怎么着?每个人都用时间真长啊来学习如何正确地做事!这意味着，在此期间会出现大量错误，并导致大量缺陷和性能瓶颈!而且要花很长时间才能修好它们!跨越每一层!每个人都可以参与每个Visual Studio项目。没有人是专门处理和优化一个问题/技术领域的。厨师多了，汤坏了。所有的厨师都会产生一些放射性粘稠物。

开发人员可能有跨层/领域的责任，但他们不应该假装自己是所有学科的大师，而应该局限于少数学科。根据我的经验，当一个项目不是一个小项目并且使用了很多技术时，在一个层中覆盖更多的业务功能比在整个体系结构堆栈中覆盖更少的业务功能(这促使开发人员只通过他们的UI而不是测试代码)更有成效(同时鼓励更多的测试代码测试该层)。

XHTML是邪恶的。编写HTML

无论如何，您都必须将MIME类型设置为text/html，所以为什么要欺骗自己相信您实际上是在编写XML呢?无论谁要下载你的页面，他都会相信这是HTML，所以把它做成HTML。

有了这些，你就可以自由而快乐地不闭上你的嘴，这是没有必要的。不要关闭html标签，文件已经结束了。它是有效的HTML，可以被完美地解析。

它将创建更可读、更少的样板代码，并且不会丢失任何东西。HTML解析器工作得很好!

当你完成后，再转向HTML5。这样更好。

关系数据库是在浪费时间。改用对象数据库!

关系数据库供应商试图欺骗我们，让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询，却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人，他们并不像你想象的那么聪明。

当然，有时在维护良好的数据库中，他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时，都必须选择编写原始SQL，这是很危险的。或者使用Object关系映射器，这会增加更多的复杂性和超出你控制的事情。

更重要的是，你被禁止提出智能搜索算法，因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下，您知道这个超级图算法，它将回答一个特定的问题，这个问题甚至可能无法用SQL表达!，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要将它与关系数据库结合起来，因为枚举一个大表将花费您数小时!

将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java，试试db4o吧。

因此，我的建议是:使用对象- db。当然，它们并不完美，有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度，对象数据库有您应该信任的查询优化器:您的大脑。

代码是设计

调试器是一种拐杖。

它的争议如此之大，以至于连我都不像以前那么相信它了。

缺点:我花了更多的时间来跟上其他人的大量代码，所以任何有助于“我是如何到达这里的”和“发生了什么”的事前或事后分析都是有帮助的。

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

在点击“发布你的答案”之前，我快速地检查了一下这个确切的短语，结果发现我不是唯一一个持有这种观点或使用这个短语的人。我在Fog Creek软件论坛上找到了关于这个问题的长时间讨论，该论坛引用了包括Linus Torvalds在内的各种名人作为著名的支持者。

Hibernate毫无用处，而且会损害开发人员的思想。

任何足够强大的库都过于复杂而无法使用，而任何足够简单而可用的库都缺乏成为良好通用解决方案所需的功能。

我经常遇到这种情况。穷尽的库，使用起来非常复杂，让我抓狂，简单易用的库，不太能做我需要做的事情。

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

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

这个不是关于编程的，因为html / css不是编程语言。

表格可以用于布局

CSS和div不能做所有的事情，节省你自己的麻烦，使用一个简单的表，然后在它上面使用CSS。

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

我不打算发布这个，因为它会惹恼所有人，我并不是真的想要一个负分或其他什么，但是:

A，这不是问题的重点吗

B)这个帖子中的大多数“答案”都证明了这一点

前几天我听到一个很好的类比:编程能力的差异至少和运动能力一样大。我们当中有多少人可以加入一个职业球队，并真正提高他们的机会?

和这里的大多数人一样，我尽量遵循DRY和不做人工编译器等原则。

我想推广的另一个策略是“告诉，不要问”。而不是混乱的所有对象与getter /setter本质上是他们的筛子，我想告诉他们做一些事情。

这似乎直接违背了具有愚蠢实体对象和较厚服务层的良好企业实践(这需要大量的请求)。嗯,想法?

我们是软件开发人员，不是C/ c# / c++ /PHP/Perl/Python/Java/…开发人员。

在你接触了几门语言之后，学习一门新的语言并高效地使用它是一个小任务。也就是说，你不应该害怕新语言。当然，提高效率和掌握一门语言是有很大区别的。但是，没有理由回避你从未见过的语言。当有人说“我是一名PHP开发人员”，或者当一份工作邀请说“Java开发人员”时，我很恼火。有了几年的开发经验后，新的语言和api真的不应该让人生畏，从从未见过一种语言到使用它的效率很高，不应该花很长时间。我知道这很有争议，但这是我的观点。

两个人的想法比一个人的好

我坚信结对编程是提高代码质量和编程效率的首要因素。不幸的是，对于那些认为“更多人手=>更多代码=> $$$!”

如果没有远程调试器，就无法编写web应用程序

Web应用程序通常将客户端和服务器端多种语言之间的交互联系在一起，需要用户进行交互，并且通常包括第三方代码，这些代码可以是简单的API实现，也可以是复杂的框架。

我已经记不清有多少次，当我用一个不错的远程调试器进入并跟踪一个复杂的web应用程序中实际发生的事情时，另一个开发人员坐在我身边，看到他们惊讶地发现有这样的工具存在。通常情况下，即使在看到这些工具的实际运行后，他们仍然不愿意费心安装和设置这些工具。

你只是不能用打印语句调试一个重要的web应用程序。如果应用程序中的所有代码都不正确，则乘以10。

如果您的调试器可以逐步检查所有正在使用的语言，并显示正在发生的http事务，那就更好了。

没有Firebug就无法开发web应用程序

同理，一旦你用过Firebug(或非常接近Firebug的东西)，你就会对那些试图开发web应用程序的人既同情又恐惧。特别是Firebug显示计算样式，如果你还记得不使用它，花了几个小时随机更改各种CSS位，并添加“!重要的”在太多的地方是有趣的，你会永远不要回头。

最新的设计模式往往是骗人的。正如之前在这个问题中所说的，过度使用设计模式对设计的危害远大于帮助。

如果我再听到一个人说“每个人都应该使用IOC”(或类似的废话)，我想我将被迫找到他们，并告诉他们他们方法的错误。

前期设计——不要因为兴奋而开始写代码

我见过很多设计糟糕的应用程序，因为开发人员太兴奋了，以至于他们直接打开白页开始写代码。我知道在开发生命周期中事情会发生变化。但是，如果应用程序具有多种不同的布局和开发方法(从一种形式到另一种形式，从一种方法到另一种方法)，则很难处理这些应用程序。

如果没有明确定义任务以及计划如何编写任务，就很难达到应用程序要处理的目标。花点时间(而不是仅仅5分钟)，确保在开始编码之前，你已经尽可能多地布局了它。这样你就可以避免顶替你的人不得不承担的意大利面条般的混乱。

避免压痕。

使用早期返回，继续或中断。

而不是:

if (passed != NULL)
{
for(x in list)
{
if (peter)
{
print "peter";
more code.
..
..
}
else
{
print "no peter?!"
}
}
}

做的事:

if (pPassed==NULL)
return false;


for(x in list)
{
if (!peter)
{
print "no peter?!"
continue;
}


print "peter";
more code.
..
..
}

我有一些…凡事都有例外，所以这些并不是一成不变的，但它们确实适用于大多数情况

没有人关心您的网站是否经过验证、是否严格遵守XHTML、是否符合标准或是否有W3C标记。

它可能会让其他Web开发人员为您击掌称赞，但其他查看您站点的人可能会关心您是否验证了代码。绝大多数上网的人都在使用IE或Firefox，因为这两种浏览器都可以容忍不标准、不严格、无效的HTML，所以你真的不用担心它。如果您为汽车经销商、机械师、广播电台、教堂或当地小企业建立了一个网站，您认为这些企业的目标人群中有多少人关心有效的HTML?我猜它很接近于0。

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

让我安装我找到的这个OSS。它看起来就像我想要的那样!等等，首先我要安装另一个窗口管理器。好的。然后我需要得到这个命令行工具，并将其添加到我的路径。现在我需要X, Y和z的最新运行时，现在我需要确保我有这些进程运行。好吧,伟大的……它已经配置好了。现在让我学习一套全新的命令来使用它。哦，酷，有人为它构建了一个GUI。我想我不需要学习这些命令。等等，我需要这个库来让GUI工作。现在就得下载。好的，现在它工作了…该死，我搞不懂这个糟糕的UI。

听起来是不是很熟悉?OSS充满了为复杂而复杂的东西，你需要成为专家才能进行复杂的安装，以及大多数人都不知道该怎么做的工具。如此多的项目半途而弃，其他的项目是如此小众以至于很少有人会使用它们，而一些不错的项目(FlowPlayer, OSCommerce等)拥有如此荒谬的过于复杂和臃肿的源代码，以至于它违背了能够编辑源代码的目的。你可以编辑源代码…如果您能找出400个文件中哪个包含需要修改的代码。当你知道总共有400个时，你就真的麻烦了。

信不信由你，我的信念，在面向对象语言中，大多数操作类数据的(业务逻辑)代码应该在类本身中在我的团队是异端。

我可能会因此被炒，但是

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

它会分散注意力，给新手带来很多微妙的bug，在我看来，这是不必要的。我所见过的唯一没有自愿遵循某种像样的格式指南的代码是来自计算机科学一年级的学生。即使代码不遵循“漂亮”的标准，也有很多工具可以将其转换成更令人满意的形状。

意见:在开发领域的持续时间并不总是等同于经验。

许多行业看重一门语言的“多年经验”。是的，5年的c#学习是有意义的，因为你可能会学到新的技巧。然而，如果你在公司工作并维护相同的代码库很多年，我觉得作为一个在不同情况和客户需求下工作的人，你似乎没有获得足够的接触不同情况的机会。

我曾经面试过一个人，他自豪地说自己有10年的编程经验，用过VB5、6和VB.Net……那段时间都在同一家公司工作。经过进一步的研究，我发现当他使用所有这些版本的VB时，他只是升级和不断地维护他原来的VB5应用程序。从不修改架构，让升级向导做他们的事情。我曾经面试过一些人，他们在这个领域只有2年的经验，但参与过多个项目，比他有更多的“经验”。

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

2. 你不需要注释你的代码。

只要陌生人能听懂就行。

因为我的答案有数百个，可能最后都没人读过，但这是我最讨厌的东西。

如果你是一名程序员，那么你很可能不擅长网页设计/开发

对于程序员来说，这个网站是一个非凡的资源，但如果您正在寻找XHTML/CSS帮助，则绝对是一个糟糕的地方。即使是优秀的Web开发人员也在提供90年代很好的资源链接!

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

此外，这个地方是一个关于网络标准建议的糟糕资源。你不应该只是编写代码在不同的浏览器中工作。您应该始终遵循标准以确保您的代码不受未来的影响。通常情况下，你在网站上使用的修复程序会在下一次浏览器更新时崩溃。不仅如此，优秀的浏览器都遵循标准。最后，IE被允许破坏互联网的原因是因为你允许它为IE编写你的网站!如果你继续在Firefox上这么做，那么我们将再次失败!

如果你认为基于表格的布局和CSS布局一样好，如果不比CSS布局好，那么你不应该被允许谈论这个话题，至少没有我先把你打倒。此外，如果你认为W3Schools是送学生去的最佳资源，那你就大错特错了。

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

有时候赶时髦是可以的

我厌倦了人们表现出“爷爷综合症”(“你们这些孩子和你们新奇的测试驱动开发。每一个过去十年里出现的大技术已经糟透了。在我的时代，我们写的是真正的代码!”你懂的)。

有时候，受欢迎的事物是有原因的。

女性比男性更适合做程序员。

与我共事过的女性程序员不像男性那样拘谨于“她们的”代码。他们更容易接受批评和新想法。

如果你只能想到一种方法，那就别去做。

无论它是一个界面布局，一个任务流，还是一个代码块，只要停止。做一些事情来收集更多的想法，比如询问其他人他们会怎么做，在你至少有三个完全不同的想法和至少一次信心危机之前，不要回去实施。

一般来说，当我认为某件事只能以一种方式完成，或者认为只有一种方法有任何优点时，那是因为我没有充分考虑应该彻底影响设计的因素。如果我这样做了，其中一些显然会发生冲突，导致混乱，从而做出实际的决定，而不是死记硬背的违约。

成为一个优秀的程序员并不意味着你就是一个优秀的界面设计师

遵循世界上所有的界面指南只会开始有所帮助。如果这是人类可能做到的…人们似乎有一种特殊的嗜好，就是把东西变得“可爱”和“聪明”。

当有人认为整个编程语言“笨拙”时，通常是因为他不知道如何使用它。

分离关注点是邪恶的:)

如果你有充分的理由，那就分开考虑。否则，不要把它们分开。

我遇到过太多只为分离而分离的场合。Dijkstra的后半句“最小的耦合，最大的内聚”不应该被忘记。：）

很高兴进一步讨论这个问题。

2空格缩进。

没有讨论。它只是必须这样;-)

我讨厌大学和研究所向新人提供短期编程课程。这完全是对编程这门艺术和科学的耻辱和蔑视。

我也不理解政府学校和大学教孩子使用商业操作系统和软件的计算机基础知识。至少在我的国家(印度)，没有多少学生买得起操作系统，甚至打折的办公套装，更不用说开发软件的巨头(编译器，ide等)。这就引发了盗窃和盗版，并使这种从他们机构的图书馆复制和窃取软件的行为成为一种正当的行为。

他们再次被教导使用一些产品，而不是基本的理念。

试想一下，如果你只被教导2x2 = 4，而没有被教导乘法的概念?

或者如果你现在被教去测量倾斜在你学校的一些复合墙的杆子的长度，而不是毕达哥拉斯定理

程序员把他们自己的(有限的)编程语言视为神圣不可侵犯的宗教。

有趣的是，程序员几乎像宗教信徒一样对待这些讨论:不允许批评，(通常)不允许客观的讨论，(通常)基于非常有限或缺乏的知识和信息进行争论。为了确认，只需阅读之前的答案，尤其是评论。

同样有趣的是，另一个确认:根据“给我一个有争议的意见”这个问题的定义，任何有争议的意见都不应该被投反对票——实际上恰恰相反:越有争议越好。但我们的程序员是如何反应的:就像巴甫洛夫的狗一样，对不喜欢的意见投反对票。

PS:为了公平起见，我给其他一些人点了赞。

软件工程师不应该和计算机科学家一起工作

牛仔程序员做得更多。

我一生都在创业的氛围中度过。如果没有牛仔编码员，我们将浪费无尽的周期来确保事情做得“正确”。

正如我们所知，预测所有问题基本上是不可能的。牛仔编码员会迎头撞上这些问题，并被迫比那些试图预见所有问题的人更快地解决它们。

不过，如果你是牛仔编码，你最好在其他人维护意大利面之前重构它。,)我所知道的最好的方法是使用持续重构。他们完成了大量的工作，不浪费时间试图预测未来，并通过重构成为可维护的代码。

过程总是阻碍一个优秀的牛仔，不管它有多敏捷。

使用设计模式和文档

在web开发中，这些东西有什么用，从来没有觉得有什么用

成员变量不应该声明为private(在java中)

如果你声明了一些私有的东西，你就阻止了任何未来的开发人员从你的类派生和扩展功能。从本质上讲，通过编写“private”，您暗示您现在比任何未来的开发人员都更了解如何使用您的类。当你写“private”的时候，你应该写“protected”。

类永远不应该声明为final(在java中)

类似地，如果您将一个类声明为final(这将阻止它被扩展—阻止它被用作继承的基类)，那么您就意味着您比任何未来的程序员都更了解使用类的正确方法。这从来不是个好主意。你不是什么都知道。有人可能会提出一个完全合适的方法来扩展你没有想到的类。

Java bean是一个糟糕的想法。

java bean约定——将所有成员声明为private，然后为每个成员编写get()和set()方法——迫使程序员在不需要代码的地方编写样板、容易出错、冗长的代码。只要将public成员变量设为public!如果您需要更改实现，请相信您以后有能力更改它(提示:99%的情况下，您永远不会更改)。

汇编语言是最好的编程语言。

Code as Design: Three Essays by Jack W. Reeves

任何软件的源代码都是其最准确的设计文档。其他的一切(规格，文档，有时还有注释)要么是不正确的，过时的，要么是误导性的。

肯定会让你在任何地方被炒。

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

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

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

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

一个懒惰的程序员可能会多花几个小时来完成第一个产品，但会为你节省几个月的时间。

Tcl/Tk是有史以来最好的GUI语言/工具包组合

它可能缺少特定的小部件，并且不如块上的新孩子好看，但它的模型是优雅的，易于使用，可以比使用可视化界面构建器更快地构建工作gui。它的表达能力是无与伦比的:其他解决方案(Gtk、Java、. net、MFC……)通常需要10到100个LOC才能得到与Tcl/Tk一行程序相同的结果。所有这些都不会牺牲可读性和稳定性。

pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]

当涉及到软件设计和开发时，设计模式是一种浪费时间的行为。

不要误解我的意思，设计模式是有用的，但主要是作为一种交流载体。它们可以非常简洁地表达复杂的思想:工厂、单例、迭代器……

但它们不应该作为一种开发方法。开发人员经常使用一系列基于设计模式的类来构建他们的代码，而在可读性和性能方面，更简洁的设计会更好。所有这些都带有一种幻想，即单个类可以在它们的域之外被重用。如果一个类不是为重用而设计的，或者不是接口的一部分，那么它就是一个实现细节。

设计模式应该被用来为组织特性命名，而不是用来规定必须编写代码的方式。

(这本来是有争议的，记得吗?)

管理者无所不知

根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。

还有一个是继第一个之后的:

没有时间把事情做对，但总有时间再做一遍

一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。

今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:

网页界面是为傻瓜准备的

上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。

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

编写完代码后再编写规格说明。(如果有的话)

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

在开发代码时牢记优化是一个好主意。

每当我这样说时，人们总是回答:“过早的优化是万恶之源”。

但我并不是说在调试之前进行优化。我甚至没有说优化，但当你在设计代码时，要记住这可能会成为一个瓶颈，并编写它，这样就有可能重构它的速度，而不会撕裂API。

雨果

这个问题让我感到有趣的是，我刚刚读了答案的第一页，到目前为止，我还没有发现一个有争议的观点。

也许这更能说明stackoverflow产生共识的方式。也许我应该从最底层开始。: -)

vb6可以用来做好事，也可以用来作恶。在编码过于复杂的时代，这是一个快速应用程序开发环境。

我过去非常讨厌VB，现在还在嘲笑VB。NET(可能是开玩笑)作为一种Fisher Price语言，因为我不喜欢经典的VB，但在它的时代，没有什么能打败它完成工作。

还没有测试它的争议，但可能有潜力:

最好的代码行是你从未写过的那行。

依赖管理软件弊大于利

我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。

像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。

问题解决了，对吧?

错了。

下载库是依赖管理的容易部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。

我不受欢迎的观点是:

如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。

同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。

您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”

当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。

我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。

使用库和框架是很好的。但总会有成本，而那些掩盖成本的工具本身就有问题。

此外，有时(注意:当然不总是)通过编写一些小类来实现你所需要的完全来重新发明轮子比引入对大型通用库的依赖更好。

goto有一些(非常少)合法的用途(特别是在C中，作为异常处理的替身)。

控制反转并不能消除依赖关系，但它确实很好地隐藏了依赖关系。

对象不应该处于无效状态

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

MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.

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

构造函数和突变方法应该原子地将对象从一种有效状态转换为另一种有效状态。这个好多了:

MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.

作为一些库的使用者，在尝试使用一个对象之前跟踪是否调用了所有正确的setter是一件非常痛苦的事情，因为文档通常没有提供关于类契约的线索。

有时，接受一个异常是合适的。

对于UI来说，用错误消息提示用户是中断的，通常他们也没什么可做的。在这种情况下，我只是记录它，并在日志中出现时处理它。

不要写代码，删除代码!

正如一位聪明的老师曾经告诉我的:“不要写代码，写代码是不好的，删除代码是好的。如果你必须写代码——写小代码……”

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

代码生成很糟糕

我讨厌那些要求你使用代码生成(或复制粘贴)来处理简单事情的语言，比如JavaBeans的Getters和Setters。

c#的AutoProperties是朝着正确方向迈出的一步，但是对于具有字段、属性和构造函数参数的dto来说，你仍然需要大量的冗余。

良好的性能VS优雅的设计

它们并不相互排斥，但我不能忍受过度设计的类结构/框架，它们完全不了解性能。我不需要有一个字符串的new This(new That(new Whatever());创建一个对象，它会告诉我现在是凌晨5点哦，顺便说一下，距离奥巴马的生日还有217天，还有两天就是周末。我只是想知道健身房开门了没有。

保持两者之间的平衡是至关重要的。当您需要将所有处理器抽出来做一些密集的事情(比如读取tb级的数据)时，代码就会变得令人讨厌。把优雅留给那些消耗10%资源的地方，这可能超过90%的代码。

对自己有争议，因为有些事情最好不说，这样你就不会被别人描绘成太过自我。然而，它是:

如果要这样，从我开始

编程是如此简单，一个五岁的孩子都能做到。

编程本身并不难，这是常识。你只是在告诉计算机该做什么。你不是天才，别自以为是了。

如果你需要阅读说明书，说明这个软件还不够好。

简单明了:-)

开发人员过度使用数据库

通常情况下，开发人员在DBMS中存储的数据应该以代码或文件的形式存在。我曾经见过一个一列一行的表，它存储“系统密码”(与用户表分开)。我看到过存储在数据库中的常量。我见过的数据库足以让一个成年程序员哭出来。

这些讨厌的程序员对DBMS有一种神秘的敬畏——数据库可以做任何事情，但他们不知道它是如何工作的。dba实践一种黑魔法。它还允许责任转移:“数据库太慢了。” “是数据库做的”和其他借口是常见的。

如果不加检查，这些程序员就会继续开发数据库中的数据库，系统中的系统。(这个反模式有一个名字，但我忘了它是什么。)

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

这是一个常见的情况，至少根据我的&我的朋友经历过，哪里都自吹自擂 程序员，问你一些他花了几周时间在谷歌上搜索的棘手问题。有趣的是，你回到家，一分钟内就把它炸飞了。这就像他们经常试图用他们的先进武器打败你，而不是检查你是否是一个全面的，务实的团队合作者。< / p >

在我看来，类似的愚蠢是当你被要求提供高度可访问的基础知识时，比如:“哦，等等，让我看看你是否能在纸上伪代码insert_name_here-algorithm(原文如此!)”。在申请高级编程工作时，我真的需要记住它吗?我应该有效地解决问题或谜题吗?

糟糕的IDE会让编程语言变弱

优秀的编程ide确实使某些语言的工作更容易，更好地监督。在我的职业生涯中，我有点被宠坏了，我工作的公司总是有最新的Visual Studio可供使用。

在过去的8个月里，我一直在做很多关于Cocoa的工作，而Xcode编辑器使得使用这种语言变得非常困难。重载很难找到，处理打开文件的整体方式只会让你的屏幕非常混乱，非常快。这真的很遗憾，因为Cocoa是一种很酷且功能强大的语言。

当然死忠的Xcode粉丝现在会投票否决我的文章，但是有很多ide确实更好。

人们正在转向IT行业，而这些人本不该转向IT行业

这是从我去年的一篇博客文章中复制/粘贴的。

我的经验主要是关于荷兰市场的，但也可以适用于任何其他市场。

我们(我将所有软件工程师归为一类)目前处于一个对我们非常有利的市场中。公司正拼命地想要得到软件工程师(从现在开始)，无论价格如何。如果你现在换工作，你几乎可以要求任何你想要的东西。在荷兰，现在有一种趋势，甚至给两辆租赁车一份工作，只是为了让你为他们工作。这有多奇怪?我怎么能同时开两辆车?

当然，这听起来对我们来说很好，但这也造成了一个非常不健康的局面。

激情，是的，我认为这个词是正确的。当你对工作充满激情时，你的工作不会在下午5点停止。您将整夜刷新所有开发RSS提要。你会在网上搜索最新的技术，在工作中使用这些技术可能会很有趣。你每个月都会开始十几个“有前途”的新项目，只是为了看看你是否能掌握几周前刚刚读到的最新技术(并找到实际使用该技术的有用方法)。

如果没有这种激情，市场可能看起来很好(因为汽车、金钱，当然还有我们吸引的辣妹)，但我认为，只要是消防员或战斗机飞行员，市场就不会那么有趣。

听起来我是在保护自己的工作，这在一定程度上是对的。但我也在努力保护自己不受我不想共事的人的伤害。我想就我读到的东西进行热烈的讨论。我希望能够与那些对工作有同样“热情”的人进行辩论。我希望同事与我共事是出于正确的原因。

我要找的人在哪里!!

使用C (/ c++)的人只有两种:一种是不懂其他语言的人，另一种是懒得学新语言的人。

学校教育毁掉创造力 *

*“废墟”指“潜在的废墟”

当然，上学是需要的!每个人在使用之前都需要学习一些东西——然而，如果我们不小心的话，你所有关于如何为特定的业务领域采取某种策略的伟大想法都很容易被扔进我们的大脑深处。

当你学习新事物、获得新技能时，你也会把自己的思维定势限制在这些新事物和新技能上，因为它们显然是“做事的方法”。作为人类，我们倾向于听从权威——无论是老师、顾问、同事，甚至是你喜欢的网站/论坛。我们应该时刻注意我们思维运作的“缺陷”。听别人说什么，但不要认为他们说的是理所当然的。对你收到的每一个新信息都要保持一种批判的观点。

而不是想“哇，这很聪明。我从现在开始就用它了”，我们应该想“哇，这很聪明。现在，我如何在我的个人技能和想法的工具箱中使用它?”

评论是不好的

当代码需要注释来解释它在做什么的时候，代码就太复杂了。我总是尝试编写足够不言自明的代码，不需要太多注释。

我不知道这是否真的有争议，但这样如何:方法名和函数名是代码中最好的注释;如果您发现自己在写注释，请将注释的代码段转换为函数/方法。

这样做有一个令人愉快的副作用，它迫使你很好地分解你的程序，避免了可能很快与现实不同步的注释，为你提供了一些可以对代码库进行grep的东西，并为你的代码留下了新鲜的柠檬味。

HTML 5 + JavaScript将是未来最常用的UI编程平台。Flash、Silverlight、Java applet等等都将无声地消亡

编程还处于初级阶段。

尽管编程语言和方法已经发展了很多年，但我们还有很长的路要走。迹象很明显:

2. 语言文档在互联网上随意传播(stackoverflow在这里有所帮助)。

3. 语言在语法上的进化必然会破坏之前的版本。

4. 调试仍然经常使用printf完成。

5. 语言库或其他形式的大规模代码重用仍然相当罕见。

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

没人在乎你的代码

如果你不从事政府安全审查项目，也不从事金融行业，那么在公司/客户基础之外，很可能没有人关心你在做什么。没有人嗅探数据包或试图侵入您的机器来读取您的源代码。这并不意味着我们应该对安全性掉以轻心，因为肯定有很多人只是想造成普遍的破坏，破坏你的辛勤工作，或者大量访问你的公司可能拥有的存储信息，如信用卡数据或身份数据。然而，我认为人们过于担心其他人能够访问您的源代码并获取您的想法。

生成文档良好的代码比生成文档不良的代码花费的时间更少

当我说证据确凿的时，我指的是在每一步都清楚地传达你的意图的注释。是的，输入注释需要一些时间。是的，你的同事都应该足够聪明，只要阅读你的描述性函数和变量名，并在你所有的可执行语句中探索他们的方式，就能弄清楚你想要什么。但如果你只是解释了你的意图，他们会花更多的时间去做，而当代码的逻辑被证明是错误的时，清晰的文档尤其有帮助。并不是说你的代码永远是错误的…

我坚信，如果从开始一个项目到发布一个没有缺陷的产品，那么编写良好文档的代码所花费的时间就会更少。首先，必须清楚地解释你在做什么，这迫使你把它想得很清楚，如果你不能写一个清晰、简洁的解释你的代码在完成什么，那么它可能设计得不好。出于另一个纯粹自私的原因，文档良好和结构良好的代码更容易交给其他人来维护——从而解放了原始作者，让他去创造下一个伟大的东西。我很少不得不停下来解释我的代码是如何工作的，因为这对任何懂英语的人来说都是显而易见的(即使他们不懂C/ c++ / c#等)。还有一个原因，坦白说，我的记性不是那么好!我不记得昨天早餐吃了什么，更不记得一个月或一年前我写代码时在想什么。也许你的记忆力比我好得多，但因为我记录了我的意图，所以我可以很快地从我中断的地方开始，并做出修改，而不需要首先弄清楚我写的时候在想什么。

这就是为什么我能很好地编写文档——不是因为我觉得编写适合展示的漂亮代码是一种崇高的使命，也不是因为我是一个纯粹主义者，而只是因为端到端让我在更短的时间内发布高质量的软件。

.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…

我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。

我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。

就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。

优秀的程序员讨厌编码

类似于“优秀的程序员是懒惰的程序员”和“代码越少越好”。但是，通过遵循这一理念，我成功地编写了一些应用程序，否则这些应用程序可能会使用几倍的代码(并花费几倍的开发时间)。简而言之:在编写代码之前先思考。我自己的程序中大部分后来导致问题的部分实际上是我喜欢编码的部分，因此代码太多，因此写得很糟糕。就像这一段。

优秀的程序员是设计师

我发现编程使用与设计相同的概念(在艺术中使用相同的设计概念)。我不确定其他程序员是否也有同样的想法;也许这是左右脑的问题。从代码到命令行用户界面，再到图形用户界面，有太多丑陋的程序，很明显，这些程序的设计者实际上并不是设计者。

尽管在这种情况下，相关性可能并不意味着因果关系，但我注意到，随着我在设计方面变得更好，我在编码方面也变得更好。创建适合和感觉对的的相同过程可以而且应该在这两个地方使用。如果代码不感觉对的，它会导致问题，因为a)它是不正确的，或者b)你会假设它以一种“感觉正确”的方式工作，然后它又会是不正确的。

艺术和代码并不是对立的;代码可以用在艺术中，代码本身也可以是一种艺术形式。

免责声明:不幸的是，并非我的所有代码都很漂亮或“正确”。

工具、方法论、模式、框架等等都不能代替一个训练有素的程序员

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

else是有害的。

得墨忒耳定律在聚合和组合上下文中被认为是一个反模式。

我的观点是，有太多的人在做编程决策时不应该担心实现。

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

去和最终用户以及想要和需要软件的人一起玩。只有从他们那里，你才能理解你的软件需要完成什么以及它需要如何完成。

• 问他们爱&讨厌现有的流程。
• 向他们询问他们的流程的未来，它的方向是什么。
• 出去逛逛，看看他们现在在用什么，弄清楚他们的使用模式。您需要满足并匹配他们的使用期望。看看他们还经常使用什么，特别是如果他们喜欢它并且可以有效地使用它。匹配。

最终用户根本不在乎你的代码有多优雅，也不在乎用什么语言写的。如果它对他们有效，他们喜欢使用它，你就赢了。如果它不能让他们的生活更轻松和更好——他们讨厌它，你就输了。

站在他们的立场上走一英里，然后去写你的代码。

永远不要让最佳实践或模式困扰成为你的奴隶。

这些应该是指导方针，而不是一成不变的法律。

我真的很喜欢这些模式，GoF的书或多或少也是这么说的，这些东西可以浏览，提供了一个常见的术语。这不是无稽之谈。

编码是一门艺术

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

“科学”派认为，既然目标是为某种情况获得最优代码，那么编码就是研究如何获得这种最优代码的科学。

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

如果它不是原生的，它就不是真正的编程

根据定义，程序是由计算机运行的实体。它直接与CPU和操作系统对话。不直接与CPU和操作系统对话的代码，而是由其他直接与CPU和操作系统对话的程序运行的代码，不是程序;这是一个脚本。

在Java出现之前，这只是简单的常识，完全没有争议。突然出现了一种脚本语言，它具有足够大的功能集，可以完成以前专属于程序的任务。作为回应，微软开发了。net框架和一些在其上运行的脚本语言，并设法通过在他们的开发工具中逐渐减少对真正编程的支持，以支持。net脚本来进一步搅浑水。

尽管它可以完成许多您以前必须编写程序才能完成的事情，但任何种类的托管代码仍然是脚本，而不是编程，用它编写的“程序”确实并且总是共享脚本的性能特征:它们运行得更慢，并且比真正的(本机)程序完成相同任务所需的内存要多得多。

人们称其为编程，这是对每个人的伤害，因为他们简化了定义。这会导致整体质量下降。如果你试图让编程变得如此简单，以至于任何白痴都能做到，那么你最终会得到一大堆自以为能编程的白痴。

认真地说，与迟钝的解析器争论，还是使用像/<a href="([^"]+)">/这样的快速正则表达式?这并不是完美的，但是您的软件可以更快地启动和运行，并且您可能还可以使用另一个正则表达式来验证提取的匹配是否确实看起来像一个URL。当然，这很俗气，而且可能在一些边缘情况下失败，但对于大多数使用来说已经足够好了。

基于大量的“如何使用正则表达式获取HTML?”的问题，几乎每天都在这里张贴，而每一个的答案是“使用HTML解析器”，这应该是有足够的争议性的。

清理和重构在(团队)开发中非常重要

团队开发中的许多工作都与管理有关。如果你正在使用漏洞追踪器，那么只有当有人花时间关闭/构建内容并降低罚单数量时，它才有用。如果你正在使用源代码管理，那么就需要经常清理和重构存储库。如果你在编程，就应该有人关心重构别人偷懒的东西。这是一些人在做软件开发时将面临的大多数方面的一部分。

大家都同意这种管理的必要性。而且它总是被跳过的第一件事!

不是工具的问题，是你的问题

每当开发人员尝试做一些新的事情，比如做UML图，任何类型的图表，项目管理，他们首先寻找完美的工具来解决问题。在无休止的寻找后，他们发现没有合适的工具，他们的动机就会枯竭。剩下的就是对缺乏可用软件的抱怨。这是一种洞察力，在没有软件的情况下，要组织的计划夭折了。

好吧，只有你自己在处理组织问题。如果你习惯了组织，你可以使用或不使用软件来完成(大多数人都不需要软件)。如果你不习惯组织，没有人能帮助你。

所以“没有合适的软件”只是没有组织的最简单的借口。

1. 好的建筑是生长出来的，而不是设计出来的。

2. 经理应该确保他们的团队成员总是在 他们的艺术状态下工作，无论那个水平是什么。当人们在自己的舒适区工作时，他们就能写出更高质量的代码。

Switch-case不是面向对象编程

我经常看到很多开关情况或可怕的大if-else结构。这仅仅是一个没有将状态放到它所属的位置的标志，并且没有使用已经存在的真正有效的开关例结构:方法查找/虚表

真正有争议的:

你什么都不知道!

换句话说:

我知道我什么都不知道。

(这可以有很多种解释，但我认为你已经明白了。)

在开始计算机开发时，我认为每个人都必须经历三个阶段:

我认为作为一个程序员，你必须知道如何学习——或者更好:学会学习(因为记住:你什么都不知道!)))。

有时您必须对数据库进行非规范化处理。

大多数程序员都不认同这种观点，但有时为了性能，你不得不牺牲一些东西，比如标准化。

编程挣钱通常是对男人时间最糟糕的利用之一。

首先，你是在和埃尔博尼亚人竞争，他们每天只挣25美分。你需要说服你的雇主，你能提供埃尔博尼亚人永远无法提供的东西，而且你的东西值得一份体面的薪水。随着埃尔博尼亚人获得越来越多的海外业务，真正的优势逐渐消失，管理层也明白这一点。

另一方面，你是在花时间解决别人的问题。这些时间你可以用来发展自己的兴趣，或者解决你真正感兴趣的问题。如果你认为解决别人的问题就能拯救世界，那你为什么不让埃尔博尼亚人为你解决问题呢?

最后，软件领域的伟大创新(visicalc、Napster、Pascal等)不是由小隔间农场创造的。它们是由一两个没有预支工资的人创建的。你不能强行重建它。当一个有能力的程序员有一个非常好的想法时，这就是奇迹。

有足够的软件。有足够多的软件开发人员。你不需要被雇佣。节省你的才华，你的时间，你的头发，你的婚姻。让别人把灵魂出卖给键盘吧。如果你想编程，没问题。但不是为了钱。

在产品代码中没有反射的位置

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

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

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

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

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

许多开发人员对在哪里放置东西没有充分的认识，导致在文件、类和方法级别上源代码组织混乱。此外，相当一部分这样的开发人员基本上对代码组织问题一无所知。试图教导、哄骗、威胁或羞辱他们保持代码干净是徒劳的。

在任何一个非常成功的项目中，通常都有一个开发人员，他有良好的组织意识，非常安静地对代码库进行扫把，以防止混乱。

我有争议的观点是John Carmack(游戏邦注:代表作有ID Software, Quake等)并不是一个优秀的程序员。

软件不是一门工程学科。

我们不应该让计算机从数学系跑出来。

设计模式是不好的。

实际上,设计模式不是。

您可以编写糟糕的代码，并将其埋没在一堆模式之下。使用单例变量作为全局变量，使用状态作为goto。无论什么。

设计模式是针对特定问题的标准解决方案，但要求您首先理解问题。如果您不这样做，设计模式就会成为下一个开发人员的问题之一。

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

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

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

“我假设用户会想要做某件事，因此我会添加这个非常酷的额外功能。”

“如果我能让我的代码解决这个不需要的场景，这将是一个使用我一直有兴趣尝试的新技术的好机会。”

实际上，满足需求的最简单的解决方案是最好的。如果出现新的需求或问题，这也为您在新的方向上采取解决方案提供了最大的灵活性。

显然我的是Haskell有变量。这既是一个“无关紧要”的问题(根据至少8个SO用户的说法)(尽管似乎没有人能就哪个无关紧要的答案是正确的达成一致)，也是一个糟糕的问题(根据至少5个反对者和4个投票关闭它的人的说法)。哦，我(以及计算科学和数学家)错了，尽管没有人能给我一个详细的解释。

您永远不会使用足够多的语言，因为每种语言只适合一小部分问题，而且混合使用语言太难了。

典型的例子:Java应该只在规范经过深思熟虑(因为有很多相互依赖关系，这意味着重构的地狱)和处理具体概念时才使用。Perl应该只用于文本处理。C语言应该只在速度压倒一切时使用，包括灵活性和安全性。键值对应该用于一维数据，CSV用于二维数据，XML用于层次数据，DB用于更复杂的数据。

我相信“让我们重写过去，假装什么都没有起作用，试着修复错误”是绝望情况下有价值的调试咒语:

https://stackoverflow.com/questions/978904/do-you-use-the-orwellian-past-rewriting-debugging-philosophy-closed < a href = " https://stackoverflow.com/questions/978904/do-you-use-the-orwellian-past-rewriting-debugging-philosophy-closed " > < / >

软件复用是优化软件开发的最重要的方法

不知怎的，软件重用一度流行，但后来失去了它的魅力，因为许多公司发现，仅仅写带有重用口号的powerpoint演示文稿实际上并没有帮助。他们认为软件重用“不够好”，无法实现他们的梦想。因此，它似乎不再流行了——它被许多项目管理新手所取代(例如敏捷)。

事实是，任何真正优秀的开发人员都会自己执行某种软件重用。我会说任何不进行软件重用的开发人员都是糟糕的开发人员!

我亲身经历过，软件重用在多大程度上可以提高开发的性能和稳定性。当然，一组幻灯片和管理层的半心半意的坦白并不足以在一家公司充分发挥其潜力。

我已经链接了一篇关于软件重用的旧文章(见标题)。它最初是用德语写的，后来被翻译了——所以，如果它写得不好，请原谅。

__abc0 __abc1 __abc2

我在很多项目中都听到过这种说法，当这种说法出现时，总是很难解决。

Emacs更好

如果一种编程语言的语法不直观，我也不在乎它有多强大，而且我不能把它放在一边，在不花太多精力刷新细节的情况下再回来使用它。我宁愿语言本身是直观的，而不是神秘但强大的用于创建DSL。计算机语言对我来说是一种用户界面，我希望它像任何其他用户界面一样易于使用。

理解“做什么”至少和知道“如何”做一样重要，而且总是比知道解决问题的“最佳”方法重要得多。领域特定的知识对于编写好的软件通常是至关重要的。

使用较短的变量名是可以的

但不是嵌套循环中的索引。

缺陷和增强请求是相同的

除非你是在一个固定价格的合同上开发软件，否则在优先考虑“bug”、“增强”和“新功能”请求之间不应该有任何区别。好吧——也许这没有争议，但我曾经在企业IT项目中工作过，那里的法令是“所有开放的bug必须在下一个版本中修复”，即使这让开发人员没有时间去开发最理想的新功能。所以，1%的用户遇到的问题，1%的时间优先于一个新功能，可能会立即对90%的用户有用。我喜欢把我的整个项目backlog，对每个项目进行评估，并把它带到用户社区进行优先级划分——其中的项目没有被归类为“缺陷”、“增强”等。

软件开发是一门艺术。

在几乎所有的情况下，注释是邪恶的:http://gooddeveloper.wordpress.com/

递归很有趣。

是的，我知道这可能是对堆栈空间的无效使用，诸如此类。但有时候递归算法比迭代算法更简洁。当我能把递归函数藏在某个地方时，我总是有点高兴。

异常应该只在真正异常的情况下使用

在我最近参与的项目中，异常的使用似乎非常猖獗。

这里有一个例子:

我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:

public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}

checkFieldExistance(req)方法从来没有返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。

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

此外，我知道checkFieldExistance(req) 做的签名抛出异常，这只是我们几乎所有的方法都这样做-所以我没有想到该方法可能会抛出异常而不是返回false。直到我翻遍代码才发现。

整天在Stackoverflow上回答问题的程序员可能并没有在做他们应该做的工作。

如果语言已经公开了实际类型，就不要为基本类型使用关键字。在c#中，这将指bool (Boolean)， int (Int32)， float (Single)， long (Int64)。'int'， 'bool'等不是语言的实际部分，而只是实际类型的'快捷方式'或'别名'。不要使用不存在的东西!在我看来，Int16, Int32, Int64，布尔值等比'short'， 'long'， 'int'更有意义。

我通常持有相当有争议的、强烈的和响亮的观点，所以这里只是其中的一些:

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

我现在工作的公司首先把自己定位为微软专家。所以前面提到的论点被抛出了很多次，我还没有看到一个背景下它是有效的。

我不明白为什么要在每一个适用的角落推广微软的技术和产品，而不顾客户和员工的满意度，以及一般的实用主义。

这正是我对软件行业政治深恶痛绝的一个基石。

MOSS(微软Office Sharepoint服务器)就是一坨屎。

有点像第一个观点，但我真的认为MOSS应该被赶出市场。它需要花费大量的授权和设置费用，破坏了web标准，让开发者非常不开心。我还没有看到一个MOSS项目有一个总体积极的结果。

然而，一次又一次，客户找到我们并要求MOSS解决方案。

Linq2Sql并没有那么糟糕

我看到过很多诋毁Linq2Sql的帖子。我知道这并不完美，但什么才是完美的?

就我个人而言，我认为它有它的缺点，但总的来说，它可以很好地用于原型设计，或开发中小型应用程序。当我考虑到它为我从编写枯燥的DAL代码中节省了多少时间时，我不能抱怨，特别是考虑到我们不久前拥有的替代方案。

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

我试着用“小于”而不是“大于”的偏好编码了一段时间，它卡住了!我不想回去，事实上，我觉得在这种情况下，每个人都应该按照我的方式去做。

考虑常用的数学“范围”符号:0 <= i <10

这很容易在代码中近似，你已经习惯了在中间重复使用&&连接变量的习惯用法:

if (0 <= i && i < 10)
return true;
else
return false;

一旦你习惯了这种模式，你就再也不会觉得愚蠢了

if ( ! (i < 0 || i >= 9))
return true;

同样的方法。

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

此外，c++标准中包含了对operator<的偏好。在某些情况下，operator=是根据它来定义的!(如!(a<b || b<a))

函数式编程并不比命令式编程更直观或更容易学习。

函数式编程有很多优点，但我经常听到函数式程序员说，对于没有编程经验的人来说，理解函数式编程比理解命令式编程更容易。据我所知，情况恰恰相反，人们发现琐碎的问题很难解决，因为他们不知道如何管理和重用他们的临时结果，当你在一个没有状态的世界结束时。

微软并不像许多人说的那么糟糕。

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

当我数苹果、员工或小部件时，我从1开始，而不是0。我也这么教我的孩子。不存在第0个苹果或第0个员工或第0个部件。使用1作为数组的基更直观，也更不容易出错。忘掉加一减一的地狱吧(我们过去常这样称呼它)。基于0的数组是计算机科学发明的一种不自然的结构——它们不能反映现实，而计算机程序应该尽可能地反映现实。

在. net上开发不是编程。它只是把其他人的代码拼接在一起。

我的编码背景要求你了解硬件，这在我的行业中仍然是一个至关重要的要求，我认为高级语言只是简单地组装别人的工作。这并没有什么本质上的错误，但这是“编程”吗?

微软在为“开发人员”提供符号指令语法方面做了很多艰苦的工作。我现在似乎认识了越来越多的开发人员，他们在执行工作时似乎受到类的存在或不存在的限制。

我的观点来自于这样一个概念:作为一名程序员，你应该能够在你的平台允许的最低水平上编程。因此，如果您正在编写。net程序，那么您需要能够埋头苦干并找出解决方案，而不是依赖于其他人为您创建一个类。在我看来，这是一种懒惰，不符合“发展”的标准。

我宁愿真正熟练/有经验的老技术，让我有效地解决现实世界的问题，而不是新的“时尚”技术，仍在经历青春期。

当许多新技术出现时，我对它们的了解只够决定我现在是否需要它们。

如果没有，我就把它们放在一边，直到“早期采用者”把粗糙的边缘去掉，然后每隔几个月/几年再检查一次。

我总是对的。

或者叫它讨论设计。但如果我提出了什么，你最好能证明我为什么错了，并提出一个你可以辩护的替代方案。

当然，这只有在我讲道理的时候才管用。幸运的是，我是。：）

可用性问题从来不是用户的错。

当某些用户做了一些团队中所有人都认为“只是一件愚蠢的事情”时，我无法计算问题出现的频率。像“为什么有人要这么做?”或者“为什么他不做XYZ”这样的短语经常出现。

尽管许多人厌倦了听我说:如果一个现实生活中的用户试图做一些事情，要么不工作，导致一些错误或导致意外的行为，那么它可以是任何人的错，但不用户的!

请注意，我不是指那些故意滥用软件的人。我指的是软件的假定目标组。

敏捷糟透了。

WordPress是一个CMS(因此在技术上确实如此)。

https://stackoverflow.com/questions/105648/wordpress-is-it-a-cms < a href = " https://stackoverflow.com/questions/105648/wordpress-is-it-a-cms " > < / >

Jon Bentley的《Programming Pearls》不再是一本有用的大部头。

http://tinyurl.com/nom56r

德尔菲很有趣

是的，我知道它已经过时了，但是Delphi是一个非常有趣的开发工具。

我认为Java应该通过精简的本地库包装器来支持特定于系统的特性。

换句话说，从几乎所有人的角度来看，我认为Sun决定要求Java只支持可移植特性是一个巨大的错误。

无数年之后，SWT出现并解决了编写可移植的本机小部件UI的基本问题，但那时微软被迫将Java派生为c#，并且已经编写了大量原本可以用文明Java完成的c++。现在世界运行在c#、VB、Java、c++、Ruby、Python和Perl的混合语言上。除了SWT程序外，所有Java程序的外观和操作都很奇怪。

如果Java在本机库周围出现了薄包装器，人们就可以编写swt等效的完全用Java编写，并且随着事情的发展，我们可以在Java中制作可移植的明显的本机应用程序。我完全支持可移植应用程序，但如果这种可移植性是在中间件UI(和其他特性)库的开放市场中实现的，而不是通过简单地将用户菜单减少为垃圾或用Swing伪造UI，那就更好了。

我猜想Sun认为ISV会受到Java的限制，然后世界上所有新的PC应用程序都会神奇地在Sun上运行。不错的尝试。他们最终没有得到应用程序，也没有让语言起飞，直到我们可以将其用于仅逻辑的服务器后端代码。

如果事情做得不一样，也许本地应用程序就不会死掉。

低级语言不适用于大多数问题。

程序员不应该接触Word(或PowerPoint)

除非你正在开发一个文字或文档处理工具，否则你不应该使用只产生二进制blobs的文字处理器，就此而言:

生成的XML文件是二进制blobs

程序员应该编写纯文本文档。程序员编写的文档只需要传达意图，而不是格式。它必须能够使用编程工具链进行生产:编辑器、版本控制、搜索实用程序、构建系统等等。当你已经拥有并知道如何使用这个工具链时，使用其他任何文档制作工具都是在浪费时间和精力。

当需要为非程序员生成文档时，应该使用轻量级标记语言，例如reStructuredText(如果您正在编写纯文本文件，您可能正在编写自己的轻量级标记)，并从中生成HTML、PDF、S5等。

软件因为缺乏多样性而糟糕透顶。无意冒犯任何种族，但当一个职业由不同种族和性别组成时，事情就会很顺利。看看过度使用不可再生能源就知道了。这很好，因为每个人都在贡献，而不仅仅是“刻板的人”

你必须懂C才能称自己为程序员!

垃圾收集被高估了

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

C必须死。

当另一种语言(比如D)可用时，自愿用C编程应该因疏忽而受到惩罚。

从长远来看，不需要探索所有形式的测试，QA也可以做得很好

很多地方似乎都有一种“方法”，“我们怎么做”。这似乎隐含地排除了其他方法。

从长远来看，这是一个严重的问题，因为QA的主要功能是将错误归档并修复它们。

如果你不能找到尽可能多的bug，你就不能很好地做到这一点。例如，当您排除方法时，由于过于依赖黑盒，您开始忽略整个可发现的编码错误类别。这意味着，您正在使整个编码错误类无法修复，除非有人偶然发现它。

潜在的问题似乎往往是管理层+员工。有这个问题的管理者似乎对计算机科学和/或他们团队的价值主张有狭隘的想法。他们倾向于创建反映他们的方法的团队，以及测试方法的白名单。

我并不是说你可以或应该一直做所有的事情。让我们面对现实吧，对于给定的产品来说，一些测试方法只是在浪费时间。有些方法在产品成熟度的特定级别上更有用。但我认为，测试组织缺少的是挑战自己学习新事物的能力，并将其应用于整体绩效。

这里有一个假设的对话可以总结:

我:你测试了10年的启动脚本，而你对shell脚本及其工作原理一无所知?!

测试人员:是的。

我:权限?

测试人员:安装程序会这样做

我:平台，发布特定的依赖?

测试者:我们为此存档bug

我:错误处理?

测试人员:当错误发生时，客户支持会给我们发送一些信息。

我:好吧…(开始考虑在stackoverflow中写帖子…)

详细的设计是浪费时间，如果一个工程师需要它们来做一份体面的工作，那么就不值得雇佣它们!

好的，这里有几个想法:

1) 瀑布开发的旧想法，你应该预先完成所有的设计，导致一些美化的极其详细的类图，序列图等等，这完全是浪费时间。正如我曾经对同事说过的，一旦代码完成，我就完成了设计。我认为敏捷在一定程度上就是对这一点的认识——代码就是设计，任何优秀的开发人员都在不断地重构。当然，这使得认为您的类图过时的想法变得可笑——它们总是过时的。

2)管理层经常认为你可以把一个糟糕的工程师当作“代码猴子”——换句话说，他们不是特别有才华，但见鬼——你就不能让他们写一些代码吗?嗯. .不!如果你不得不花很多时间来写详细的规范，你基本上是在指定代码，那么你自己写会更快。你没有节省任何时间。如果开发者不能聪明地运用自己的想象力和判断力，他们就不值得雇佣。(注意，我不是在谈论能够学习的初级工程师。很多“高级工程师”都属于这一类。)

当为数据访问层创建单元测试时，数据应该直接从DB中检索，而不是从模拟对象中检索。

考虑以下几点:

void IList<Customer> GetCustomers()
{
List<Customer> res = new List<Customer>();


DbCommand cmd = // initialize command
IDataReader r = cmd.ExecuteQuery();


while(r.read())
{
Customer c = ReadFiledsIntoCustomer(r);
res.Add(c);
}


return res;
}

在GetCustomers的单元测试中，对cmd.ExecuteQuery()的调用应该实际访问DB还是应该模拟它的行为?

我认为，如果以下情况成立，您不应该模拟对DB的实际调用:

1. 存在一个测试服务器和模式。
2. 模式是稳定的(意味着您不期望对其进行重大更改)
3. DAL没有聪明的逻辑:查询被简单地构造(config/stored procs) 去虹膜化逻辑很简单

从我的经验来看，这种方法的最大好处是你可以尽早与DB进行交互，体验“感觉”，而不仅仅是“外观”。它为您省去了许多事后的麻烦，并且是熟悉模式的最佳方法。

许多人可能会争辩说，一旦执行流跨越了进程边界，它就会成为一个单元测试。我同意它有它的缺点，特别是当数据库不可用，然后你不能运行UT。

然而，我相信在许多情况下这应该是一件有效的事情。

记事本是一个完美的文本编辑器。(有时是非窗口换行符的写字板)

• 编辑配置文件
• 查看日志文件
• 发展

我知道有人真的相信这一点!然而，他们将使用IDE进行开发，但继续使用记事本进行其他一切!

应该要求所有项目经理都有编码任务

在我工作过的团队中，项目经理实际上是一个程序员，他非常了解代码的技术问题，足以完成编码任务，所做的决策缺乏沟通脱节，而在项目经理不参与代码的团队中经常发生这种情况。

开发项目一定会失败，除非程序员团队作为一个整体被赋予完全的权力来做出与所使用的技术相关的所有决策。

至少从gprof的论文开始，测量的思想就已经成为常识 (苏珊·l·格雷厄姆等，1982年)*，而一直以来，就在我们的鼻子底下，一直是非常简单和直接的方法找到值得优化的代码.

作为一个小例子，下面是它的工作原理。假设您从调用堆栈中抽取5个随机时间样本，并且恰好在5个样本中的3个样本中看到特定的指令。这说明了什么?

.............   .............   .............   .............   .............
.............   .............   .............   .............   .............
Foo: call Bar   .............   .............   Foo: call Bar   .............
.............   Foo: call Bar   .............   .............   .............
.............   .............   .............   Foo: call Bar   .............
.............   .............   .............   .............   .............
.............                                   .............

它告诉你程序花费60%的时间来完成指令请求的工作 > < /强。去掉它就去掉了60%:

...\...../...   ...\...../...   .............   ...\...../...   .............
....\.../....   ....\.../....   .............   ....\.../....   .............
Foo: \a/l Bar   .....\./.....   .............   Foo: \a/l Bar   .............
......X......   Foo: cXll Bar   .............   ......X......   .............
...../.\.....   ...../.\.....   .............   Foo: /a\l Bar   .............
..../...\....   ..../...\....   .............   ..../...\....   .............
/     \      .../.....\...                      /     \      .............

很快我们将在一个没有的世界里编程 数据库> < /强劲。< / p > < /李> 的GOTO是

• 21世纪.

. 构建软件是一项社会活动 活动，不是技术性的。

• 乔尔有一个博客。

引用已故的E. W. Dijsktra的话:

编程是应用数学中最难的分支之一;贫穷的数学家最好还是做纯粹的数学家。

计算机科学与计算机无关，就像天文学与望远镜无关一样。

我不明白一个人怎么能声称自己是一个合格的程序员，却不能解决像这一个这样非常简单的数学问题。可能是一个CRUD猴子，但不是一个程序员。

真正的程序员像爱灵魂伴侣一样爱开源，像爱肮脏但令人满意的妓女一样爱微软

“程序员必须把编程作为副业，否则他们永远都不如做编程的人。”

就像kpollock说的，想象一下对于医生或士兵来说……

最重要的不是他们是否编码，而是他们是否思考编码。计算科学是一种智力练习，你不一定需要编写代码来思考使你成为更好的程序员的问题。

这并不像爱因斯坦在他的研究之外还能玩粒子和波。

程序员应该不惜一切代价避免通过继承隐藏方法。

根据我的经验，几乎我所见过的所有使用继承方法隐藏的地方都会引起问题。方法隐藏导致对象在通过基类型引用和派生类型引用访问时行为不同——这通常是一件坏事。虽然许多程序员没有正式意识到它，但大多数人直观地期望对象将遵循利斯科夫替换原理。当对象违反这一期望时，面向对象系统固有的许多假设就会开始动摇。我见过的最糟糕的情况是隐藏方法改变了对象实例的状态。在这些情况下，对象的行为可能以难以调试和诊断的微妙方式发生变化。

好吧，可能在一些罕见的情况下，方法隐藏实际上是有用和有益的——比如在不支持方法隐藏的语言中模拟方法的返回类型协方差。但是大多数时候，当开发人员使用方法时，隐藏方法要么是出于无知(或意外)，要么是作为一种绕过一些可能需要更好设计处理的问题的方法。一般来说，我所见过的方法隐藏(并不是说没有其他方法)的有益情况是，一个返回一些信息的无副作用方法被一个计算更适用于调用上下文的方法所隐藏。

像c#这样的语言对隐藏基类方法的方法要求new关键字进行了一些改进——至少有助于避免非自愿地使用方法隐藏。但我发现许多人仍然混淆了new和override的含义——特别是因为在简单的场景中，它们的行为可能看起来相同。如果像FxCop这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。

顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。

有争议的是吗?我认为c++流使用<<和> >。我讨厌它。它们是移位运算符。以这种方式重载它们显然是一种糟糕的做法。这让我想杀了想出这主意并认为这是个好主意的人。叽阿。

匿名函数很糟糕。

我正在自学jQuery，虽然它是一种优雅且非常有用的技术，但大多数人似乎都将其视为最大化匿名函数用户的某种竞争。

函数和过程命名(以及变量命名)是我们在编程中所拥有的最强大的表达能力。将函数作为数据传递是一项伟大的技术，但使它们匿名并因此非自文档化是一个错误。这样就失去了表达代码含义的机会。

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

不要改变未坏的东西。

我要说的是，我对编程最具争议的观点是，我真的认为你不应该太担心被丢弃的代码和重写代码。很多时候，人们觉得如果你写了一些东西，那么改变它就意味着你做错了什么。但是我的大脑工作的方式是让一些非常简单的东西工作，并缓慢地更新代码，同时确保代码和测试继续一起工作。它最终可能会创建类、方法、附加参数等等，我完全知道这些在几个小时内就会消失。但我这样做是因为我只想朝着我的目标迈出一小步。最后，我不认为我花在使用这种技术上的时间比那些盯着屏幕试图在写一行代码之前找出最佳设计的程序员更多。

我得到的好处是，我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件，并试图找出停止工作的原因和原因。

复制/粘贴是万恶之源。

如果你曾经让rentacoder.com的任何人接触过你的项目，那么这个项目和你的业务就完全没有价值了。

面向对象编程被过度使用

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

如果你没有读过手册页，你就不是一个真正的程序员。

我有两个:

设计模式有时是糟糕程序员编写糟糕代码的一种方式 -“当你有一个锤子，整个世界看起来像一个钉子”的心态。如果有什么我讨厌听到的是两个开发人员通过模式创建设计:“我们应该使用命令与facade…”

没有所谓的“过早优化”。你应该在你觉得这样做太痛苦之前对你的代码进行分析和优化。

“评论是谎言”

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

我们不写注释，因为它们很冗长，而且模糊了代码中真正发生的事情。如果你觉得需要注释——找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释……

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

编程:这是一个有趣的工作。

我似乎看到了两类开发人员。有些人不喜欢，但他们有能力，薪水也不错。另一组人喜欢它的程度有点令人毛骨悚然。这似乎就是他们的生活。

我只是觉得这份工作薪水高，而且有趣。每一天的每一分钟都有各种各样的学习新东西的空间。我想不出其他我更喜欢的工作了。但这仍然是一份工作。妥协是要做出来的，你生产的东西并不总是那么好。

因为我更愿意在沙滩上喝啤酒或和孩子们一起玩。

你只需要3到5种语言就可以完成所有的事情。C是定的。也许是组装，但你应该知道它，并能使用它。如果你写的是网页代码，可能是javascript和/或Java。一种shell语言(如bash)和一种HLL语言(如Lisp)可能会有用。其他任何事情都会让人分心。

复制/粘贴不是反模式，事实上它有助于避免产生更多的错误

我的经验法则——只输入不能复制/粘贴的东西。如果创建类似的方法，类或文件-复制现有的并更改所需的内容。(我不是在谈论复制应该放在单个方法中的代码)。

我通常从不输入变量名——要么复制粘贴，要么使用IDE自动补全。如果需要一些DAO方法-复制类似的方法并更改所需的内容(即使将更改90%)。对某些人来说，这可能看起来是极度的懒惰或缺乏知识，但我几乎从来没有处理过由拼写错误引起的问题，而且它们通常很难捕捉(如果没有在编译级别检测到)。

每当我偏离我的复制粘贴规则，开始输入东西时，我总是拼写错误(这只是一个统计数据，没有人能立即写出完美的文本)，然后花更多的时间试图找出哪里。

只有一种设计模式:封装

例如:

• 工厂方法:您已经封装了对象创建
• 策略:封装了不同的可变算法
• 迭代器:您封装了按顺序访问集合中的元素的方法。

现代c++是一门美丽的语言。

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

我认为大多数讨厌c++的人都是基于使用OO的糟糕经历。c++在面向对象方面做得不是很好，因为多态性通常依赖于堆分配对象，而且c++没有自动垃圾收集。

但c++真正的亮点在于泛型库和函数式编程技术，这使得构建难以置信的大型、高度可维护的系统成为可能。很多人说c++试图做所有事情，但最终什么都做不好。我可能同意它在面向对象方面不如其他语言，但它在泛型编程和函数式编程方面比任何其他主流的基于c的语言都要好。(c++ 0x只会进一步强调这一事实。)

我也很欣赏c++如何让我在必要时获得底层，并提供对操作系统的完全访问。

加上RAII。认真对待。当我用其他c语言编程时，我真的很想念析构函数。(不，垃圾回收不会使析构函数无用。)

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

可配置软件允许最终用户(或管理员等)选择太多的选项，这些选项可能没有一起测试过(或者，如果有超过非常小的数量，我可以保证没有测试过)。

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

一个很好的例子是谷歌Chrome上的配置选项的数量-然而，这可能仍然太多:)

三元操作符绝对糟糕。他们是懒惰编程的典型代表。

user->isLoggedIn() ? user->update() : user->askLogin();

这太容易搞砸了。修订2的一个小变化:

user->isLoggedIn() && user->isNotNew(time()) ? user->update() : user->askLogin();

哦，是的，只是一个“小改变”。

user->isLoggedIn() && user->isNotNew(time()) ? user->update()
: user->noCredentials() ? user->askSignup
: user->askLogin();

哦，糟了，那另一个案子呢?

user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned() ? user->update()
: user->noCredentials() || !user->isBanned() ? user->askSignup()
: user->askLogin();

不不不不。只需要为我们保存代码更改。别再那么懒了:

if (user->isLoggedIn()) {
user->update()
} else {
user->askLogin();
}

因为如果第一次就做对了，我们就不必一次又一次地改变你的垃圾三元组:

if (user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned()) {
user->update()
} else {
if (user->noCredentials() || !user->isBanned()) {
user->askSignup();
} else {
user->askLogin();
}
}

c++的STL库是如此通用，以至于它对任何人都不是最优的。

JavaScript是一种“混乱”的语言，但上帝保佑我，我喜欢它。

从长远来看，开源软件的成本更高

对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。

当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。

精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。

修饰你的代码，使它看起来更大。

显然，IDE应该检查是有争议的，看看他们是否可以在浪费时间编译之前链接他们创建的代码

但我的观点是，我不应该编译无数行代码才意识到Windows对我试图创建的文件有一个锁，因为另一个程序员有一些奇怪的线程问题，要求他在dll不应该被使用后延迟卸载3分钟。

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

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

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

1. 类型检查
2. 断言
3. 简单可验证的代码

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

过程式编程很有趣。OOP很无聊。

Java是我们这一代的COBOL语言。

每个人都要学会编码。在大公司中有运行它的代码，这些公司会试图让它运行几十年。与所有其他选择相比，每个人都开始鄙视它，但无论如何都被迫使用它，因为它可以支付账单。

XML和HTML是web的“汇编语言”。为什么还要黑它?

很明显，现在很少有开发人员学习汇编语言/编写代码，因为它很原始，并且使您远离必须在高层解决的问题。所以我们发明了高级语言来封装这些级别的实体，通过我们可以在更高级别上联系到的语言元素来提高我们的工作效率。就像我们可以用计算机做更多的事情，而不仅仅是它的组成部分主板或CPU。

对于Web，在我看来，开发人员仍然在阅读/编写和破解HTML、CSS、XMl、模式等。

人脑是开启所有锁的万能钥匙。

世界上没有任何东西能让你的大脑运转得更快。相信我，这不是哲学上的，而是实际的。就意见而言，他们就像下面一样

1)永远不要超出编程语言指定的界限，一个简单的例子就是C和c++中的指针。不要误用它们，因为你可能会得到该死的分割错误。

2)始终遵循编码标准，是的，你读的是正确的，编码标准对你的程序有很大影响，毕竟，你的程序是被机器执行的，而不是被其他大脑理解的:)

汇编程序没有死

在我的工作(复制保护系统)中，汇编程序是必不可少的，我使用了许多hll复制保护系统，只有汇编程序才能真正地利用隐藏在代码中的所有可能性(如代码突变，低级别的东西)。

此外，许多代码优化只有通过汇编程序才能实现，看看任何视频编解码器的源代码，源代码都是用汇编程序编写的，并优化为使用MMX/SSE/SSE2操作码，许多游戏引擎使用汇编程序优化例程，甚至Windows内核也有SSE优化例程:

NTDLL.RtlMoveMemory


.text:7C902CD8                 push    ebp
.text:7C902CD9                 mov     ebp, esp
.text:7C902CDB                 push    esi
.text:7C902CDC                 push    edi
.text:7C902CDD                 push    ebx
.text:7C902CDE                 mov     esi, [ebp+0Ch]
.text:7C902CE1                 mov     edi, [ebp+8]
.text:7C902CE4                 mov     ecx, [ebp+10h]
.text:7C902CE7                 mov     eax, [esi]
.text:7C902CE9                 cld
.text:7C902CEA                 mov     edx, ecx
.text:7C902CEC                 and     ecx, 3Fh
.text:7C902CEF                 shr     edx, 6
.text:7C902CF2                 jz      loc_7C902EF2
.text:7C902CF8                 dec     edx
.text:7C902CF9                 jz      loc_7C902E77
.text:7C902CFF                 prefetchnta byte ptr [esi-80h]
.text:7C902D03                 dec     edx
.text:7C902D04                 jz      loc_7C902E03
.text:7C902D0A                 prefetchnta byte ptr [esi-40h]
.text:7C902D0E                 dec     edx
.text:7C902D0F                 jz      short loc_7C902D8F
.text:7C902D11
.text:7C902D11 loc_7C902D11:                           ; CODE XREF: .text:7C902D8Dj
.text:7C902D11                 prefetchnta byte ptr [esi+100h]
.text:7C902D18                 mov     eax, [esi]
.text:7C902D1A                 mov     ebx, [esi+4]
.text:7C902D1D                 movnti  [edi], eax
.text:7C902D20                 movnti  [edi+4], ebx
.text:7C902D24                 mov     eax, [esi+8]
.text:7C902D27                 mov     ebx, [esi+0Ch]
.text:7C902D2A                 movnti  [edi+8], eax
.text:7C902D2E                 movnti  [edi+0Ch], ebx
.text:7C902D32                 mov     eax, [esi+10h]
.text:7C902D35                 mov     ebx, [esi+14h]
.text:7C902D38                 movnti  [edi+10h], eax

所以，如果你下次听到汇编器死了，想想你最近看过的电影或玩过的游戏(以及它的复制保护)。

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

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

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

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

我敢肯定有些人喜欢解析文字，将艺术和科学的定义扩展到包括编程，或将工程限制为机械机器或硬件。查字典。此外，“计算机编程艺术”是艺术的另一种用法，指的是一种技能或工艺，如“对话的艺术”。编程的产物不是艺术。

Visual Basic和c#都不能胜过对方。除了一些语法和格式之外，它们几乎是一样的。

不是真正的编程，但我不能忍受css只布局只是为了它。它会适得其反，令人沮丧，并且使维护成为浮动和页边距的噩梦，因为改变单个元素的位置可能会使整个页面混乱。

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

我觉得我们应该放弃C。它太旧了!但是，老狗还是叫得更响了!!

宏， 预处理器指令和注释是邪恶的。

每个文件只使用一种语法和语言!

//不适用于Make文件或插入真实代码的编辑器宏。

布尔变量只能用于布尔逻辑。在所有其他情况下，使用枚举。

布尔变量用于存储只能有两个可能值的数据。使用它们所产生的问题经常被忽视:

• 程序员通常不能正确地识别某些数据何时应该只有两个可能的值
• 指导程序员做什么的人，比如程序经理或编写程序员遵循的规范的人，通常也不能正确地识别这一点
• 即使一段数据被正确地识别为只有两种可能的状态，这种保证在将来也可能不成立。

在这些情况下，使用布尔变量会导致令人困惑的代码，这通常可以通过使用枚举来避免。

例子

假设一个程序员正在为一家只销售轿车和卡车的汽车经销商编写软件。程序员为他的软件开发一个全面的业务需求模型。由于知道所销售的车辆只有轿车和卡车两种类型，他正确地识别出可以在Vehicle类中使用一个布尔变量来指示车辆是轿车还是卡车。

class Vehicle {
bool isTruck;
...
}

该软件是这样编写的，当isTruck为真时，车辆是卡车，当isTruck为假时，车辆是汽车。这是在整个代码中执行多次的简单检查。

一切都很顺利，直到有一天，汽车经销商收购了另一家同样销售摩托车的经销商。程序员必须更新软件，使其能够正确地考虑到经销商的业务发生了变化。现在它需要识别车辆是汽车、卡车还是摩托车，这是三种可能的状态。

程序员应该如何实现这一点?isTruck是一个布尔变量，所以它只能保存两种状态。他可以将其从布尔类型更改为允许多种状态的其他类型，但这将破坏现有的逻辑，并且可能无法向后兼容。从程序员的角度来看，最简单的解决方案是添加一个新变量来表示车辆是否是摩托车。

class Vehicle {
bool isTruck;
bool isMotorcycle;
...
}

代码更改为:当isTruck为真时，车辆为卡车;当isMotorcycle为真时，车辆为摩托车;当它们都为假时，车辆为汽车。

问题

这种解决方案存在两个大问题:

• 程序员想要表达车辆的类型，这是一个想法，但解决方案使用两个变量来实现这一点。不熟悉代码的人要理解这些变量的语义要比程序员只用一个变量来完全指定类型困难得多。
• 通过添加一个新的布尔值来解决这个摩托车问题并不能让程序员更容易地处理将来发生的这种情况。如果经销商开始销售总线，程序员将不得不通过添加另一个布尔值来重复所有这些步骤。

软件的业务需求发生变化，要求他修改现有代码，这不是开发人员的错。但是首先使用布尔变量使得他的代码不那么灵活，也更难修改以满足未知的未来需求(不那么“适合未来”)。当他以最快的方式实现更改时，代码变得难以阅读。使用布尔变量最终是一个不成熟的优化。

解决方案

首先使用枚举就可以避免这些问题。

enum EVehicleType { Truck, Car }


class Vehicle {
EVehicleType type;
...
}

为了在这种情况下容纳摩托车，程序员所要做的就是将Motorcycle添加到EVehicleType，并添加新的逻辑来处理摩托车的情况。不需要添加新的变量。现有的逻辑不应该被打乱。不熟悉代码的人也很容易理解车辆的类型是如何存储的。

悬崖笔记

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

一个文件一个类

谁在乎呢?我更喜欢把整个程序包含在一个文件中，而不是一百万个不同的文件。

你不知道也没关系。但如果你连个屁都不会，你就会被解雇。

互联网是一个工具。如果你从中吸取教训，它不会让你变笨。

不要害羞，抛出异常。 异常是表示故障的一种非常有效的方式，比任何返回码系统都清晰得多。“异常”与这种情况发生的频率无关，而与类认为的正常执行条件有关。当发生除零时抛出异常就可以了，不管这种情况发生的频率有多高。如果可能出现问题，请保护您的代码，以免使用不正确的参数调用方法

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

根据我的经验，当涉及到使用第三方代码来解决问题时，似乎有太多的热情。人们通常不会想到自己解决问题的办法。不要误解我的意思，我并不是要宣扬永远不要使用库。我的意思是:在您正在考虑使用的可能的框架和模块中，添加自己实现解决方案的选项。

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

• 不要白费力气。但是，如果你只需要一块木头，你真的需要一个完整的车轮吗?换句话说，你真的需要openCV来沿轴翻转图像吗?
• 妥协。为了能够使用特定的库，您通常必须在设计方面做出妥协。您必须合并的更改量是否值得您将获得的功能?
• 学习。你必须学会使用这些新的框架和模块。你要花多长时间?值得你这么做吗?学习的时间会比实施的时间长吗?
• 成本。不是所有的东西都是免费的。不过，这包括你的时间。考虑一下你将要使用的软件将为你节省多少时间，以及它是否物有所值?(也要记住，你必须投入时间去学习)
• 你是程序员，不是…一个人只是把东西放在一起(对不起，想不出任何诙谐的东西)。

最后一点是有争议的。

在很多情况下，使用正则表达式解析HTML是可以的

每次有人在Stack Overflow上发布一个问题，询问如何用正则表达式实现HTML操作，第一个答案是“正则表达式是一个不足以解析HTML的工具，所以不要这样做”。如果提问者试图构建一个网络浏览器，这将是一个有用的回答。然而，通常提问者想要做一些事情，比如向某个域的所有链接添加rel标记，通常是在可以对传入标记的样式做出某些假设的情况下，这对于正则表达式来说是完全合理的。

将XML存储在关系数据库中的CLOB中通常是一种可怕的逃避。它不仅在性能方面很糟糕，还将正确管理数据结构的责任从数据库架构师转移到应用程序程序员身上。

软件就像厕纸。你花的越少，它就越麻烦。

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

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

企业外部的人对你的业务模式了解较少，因此不会很好地为企业内部的系统编程。此外，他们知道他们不必支持它，所以除了半途而废之外，没有动力去做任何事情。

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

我在这里不仅仅是在谈论MOSS，我也使用过一些其他的企业内部网产品，绝对没有一个是好的，但是SharePoint (MOSS)是目前为止最差的。

• 大多数这样的系统都不容易弥合内部网和Internet之间的差距。所以作为一名远程工作者，你不得不使用VPN。外部客户根本没有机会直接掌握你的内部信息。当然，这个问题可以以$$$的价格解决。
• 搜索功能总是很可怜。很多时候，其他部门根本不知道信息在那里。
• 信息碎片，人们开始抵制工作流程或回复电子邮件
• SharePoint开发是世界上最痛苦的开发形式。没有什么比SharePoint更糟糕了。我见过一些开发人员在MOSS工作了一年多后考虑放弃IT。
• 不管开发人员多么讨厌MOSS，不管最基本的项目需要多长时间才能推出，不管结果看起来多么新手，不管内容多么难以搜索和碎片化:

每个人仍然在继续使用和购买sharepoint，经理们仍然非常努力地假装它不是撒旦的产物。

微格式

使用最初为视觉布局设计的CSS类——现在被分配给视觉和上下文数据是一种hack，充满了歧义。不是说这个功能不应该存在，而是修复这个该死的基础语言。HTML并不是为了产生XML而被破解的——相反，XML语言出现了。现在我们有这些热切的脚本孩子黑客HTML和CSS做一些它不是设计来做的，这仍然是好的，但我希望他们能把这些事情留给自己，而不是制定一个标准。只是去屠杀!

关联数组/哈希映射/哈希表(无论它在你最喜欢的语言中叫什么)是自切片面包以来最好的东西!

当然，它们提供了从键到值的快速查找。但它们也使动态构造结构化数据变得容易。在脚本语言中，它通常是表示结构化数据的唯一(至少是最常用的)方法。

恕我直言，它们是许多脚本语言成功的一个非常重要的因素。

甚至在c++中std::map和std::tr1::unordered_map帮助我更快地编写代码。

c++是未来的杀手级语言…

．.． 动态语言。

没有人拥有它，它有越来越多的特性，比如编译时(元)编程或类型推断，没有函数调用开销的回调，不强制单一方法(多范式)。POSIX和ECMAScript 正则表达式。多个返回值。你可以有命名参数。等等。

编程的过程非常缓慢。JavaScript花了10年的时间才起步(主要是因为性能)，大多数用它编程的人仍然不理解它(JS中的类?来吧!)我敢说c++将在15-20年后真正开始发光。对我来说，这似乎是c++(语言以及编译器供应商)和当今使用动态语言编写的程序员的适当时间。

c++需要变得对程序员更加友好(编译器错误是由模板或编译时间生成的)，程序员需要意识到静态类型是一个福音(它已经在进行中，参见这里断言用动态类型语言编写的好代码就像编写静态类型语言一样)。

关系数据库系统将是自切片面包以来最好的东西…

．.． 那就是当我们(希望)得到它们的时候。SQL数据库太糟糕了，一点都不好笑。

我觉得有趣(如果悲伤)的是dba认证认为SQL数据库系统是关系型的。这说明了上述认证的质量。

困惑吗?读c·j·戴特的书。

编辑

为什么它被称为关系，这个词是什么意思?

如今，拥有强大(哎呀，任何)数学背景的程序员(或经过认证的DBA， 眨眼)是例外，而不是常见情况(我也是常见情况的一个实例)。SQL的表， 列和行，以及被称为实体/关系建模的笑话只是在伤害上增加了侮辱。难怪关系数据库系统之所以这样叫，是因为实体(表)之间的一些的关系(外键?)是如此普遍的误解。

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

[http://en.wikipedia.org/wiki/Finitary_relation] [2]:

在数学中(更具体地说，在集合论和逻辑中)，关系是一个属性，它将真值赋给k个体的组合(k-元组)。通常，该属性描述了k-tuple的组件之间可能的连接。对于给定的一组k-tuple，根据属性是否存在，为每个k-tuple分配一个真值。

三元关系(即三个个体之间)的一个例子是:"X被Z引入到Y "，其中(X,Y,Z)是人的3元组;例如，“比阿特丽斯·伍德是由马塞尔·杜尚介绍给亨利-皮埃尔Roché”是真的，而“卡尔·马克思是由维多利亚女王介绍给弗里德里希·恩格斯的”是假的。

维基百科说得很清楚:在SQL数据库管理系统中，这样的三元关系将是“表格”，而不是“外键”(我冒昧地重命名关系的“列”:X = who, Y = to, Z = by):

CREATE TABLE introduction (
who INDIVIDUAL NOT NULL
, to INDIVIDUAL NOT NULL
, by INDIVIDUAL NOT NULL
, PRIMARY KEY (who, to, by)
);

此外，它还可能包含(在其他对象中)这个"行":

INSERT INTO introduction (
who
, to
, by
) VALUES (
'Beatrice Wood'
, 'Henri-Pierre Roché'
, 'Marcel Duchamp'
);

但不是这个:

INSERT INTO introduction (
who
, to
, by
) VALUES (
'Karl Marx'
, 'Friedrich Engels'
, 'Queen Victoria'
);

关系数据库字典:

关系(数学)给定集合s1， s2，…r是这些集合上的一个关系，当且仅当它是__abc5元组的集合，其中每个元组的第一个元素来自s1，第二个元素来自s2，等等。(等价地，r是笛卡尔积s1 x s2 x…x sn。)

集合如果是r的我域(我 = 1，…n)。请注意:在数学关系和对应的关系模型之间有几个重要的逻辑差异。以下是其中一些:

• 数学关系的属性有从左到右的顺序。
• 实际上，数学关系充其量只有一个非常基本的属性概念。当然，它们的属性没有被命名，除了它们的序号位置。
• 因此，在关系模型的意义上，数学关系实际上既没有标题也没有类型。
• 数学关系通常是二元的，偶尔也是一元的。相比之下，关系模型中的关系的度数为n，其中n可以是任何非负整数。
• 关系操作符，如JOIN、EXTEND和其他操作符，首先是在关系模型的上下文中定义的;关系的数学理论很少包含这样的运算符。

依此类推(上述并不是一个详尽的列表)。

开发80%是关于设计，20%是关于编码

我认为开发者应该将80%的时间用于设计细节，即他们将要构建的内容，而只有20%的时间用于编写他们所设计的内容。这将产生几乎零错误的代码，并在测试-修复-重新测试周期中节省大量时间。

过早地进入金属(或IDE)就像过早的优化，这被认为是万恶之源。深思熟虑的前期设计(我说的不一定是庞大的设计文档，简单的白板图纸也可以)会比编码和修改产生更好的结果。

简单Vs优化

我相信编写既简单又最佳的代码是非常困难的。

(这一观点的灵感来自于Dima Malenko的回答。“开发80%是关于设计，20%是关于编码”，没错。“这将产生几乎零错误的代码”，不。)

最佳实践则不然。

小代码总是更好，但是复杂?:而不是if-else让我意识到有时大代码更可读。

Python用一半的开发时间就完成了其他编程语言所做的一切……谷歌也是!!如果你不同意，请查看Unladen Swallow。

等等，这是事实。它还能回答这个问题吗?

低驼峰是愚蠢和没有语义的

使用lower camelCase使名称/标识符(从这里开始使用“name”)看起来像两个部分。然而，Upper CamelCase给出了清晰的指示，所有的单词都属于一起。

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

有些人可能会认为小写的驼峰大小写应该用于函数/过程，特别是在类内部。这在Java和面向对象的PHP中很流行。然而，没有理由这样做来表明它们是类方法，因为通过访问它们的方式它变得非常清楚，这些只是类方法。

一些代码示例:

# Java
myobj.objMethod()
# doesn't the dot and parens indicate that objMethod is a method of myobj?


# PHP
$myobj->objMethod()
# doesn't the pointer and parens indicate that objMethod is a method of myobj?

Upper CamelCase对于类名和其他静态名很有用。所有非静态内容都应该通过它们的访问方式来识别，而不是通过它们的名称格式(!)

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

# Java
my_obj = new MyObj() # Clearly a class, since it's upper CamelCase
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # Clearly an attribute, since it's referenced


# PHP
$my_obj = new MyObj()
$my_obj->obj_method()
$my_obj->obj_var
MyObj::MyStaticMethod()


# Python
MyObj = MyClass # copies the reference of the class to a new name
my_obj = MyObj() # Clearly a class, being instantiated
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # clearly an attribute, since it's referenced
my_obj.obj_method # Also, an attribute, but holding the instance method.
my_method = myobj.obj_method # Instance method
my_method() # Same as myobj.obj_method()
MyClassMethod = MyObj.obj_method # Attribute holding the class method
MyClassMethod(myobj) # Same as myobj.obj_method()
MyClassMethod(MyObj) # Same as calling MyObj.obj_method() as a static classmethod

这就是我对camelCase完全主观的看法。

程序员需要与客户交流

一些程序员认为，他们不需要成为与客户交谈的人。对于你的公司来说，这是一种肯定的方式，可以写出一些绝对出色的东西，没有人知道它是用来做什么的，也没有人知道它是如何被使用的。

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

如果你想写出最好的代码，你希望人们使用它。对你的用户群感兴趣，向那些“愚蠢的傻瓜”学习。别害怕，他们会因此爱上你的。

过分遵守标准会妨碍简单。

MVC对于网站来说被高估了。主要是VC，有时是M。