Never make up your mind on an issue before thoroughly considering said issue. No programming standard EVER justifies approaching an issue in a poor manner. If the standard demands a class to be written, but after careful thought, you deem a static method to be more appropriate, always go with the static method. Your own discretion is always better than even the best forward thinking of whoever wrote the standard. Standards are great if you're working in a team, but rules are meant to be broken (in good taste, of course).

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

When I say well-documented I mean with comments that communicate your intention clearly at every step. Yes, typing comments takes some time. And yes, your coworkers should all be smart enough to figure out what you intended just by reading your descriptive function and variable names and spelunking their way through all your executable statements. But it takes more of their time to do it than if you had just explained your intentions, and clear documentation is especially helpful when the logic of the code turns out to be wrong. Not that your code would ever be wrong...

I firmly believe that if you time it from when you start a project to when you ship a defect-free product, writing well-documented code takes less time. For one thing, having to explain clearly what you're doing forces you to think it through clearly, and if you can't write a clear, concise explanation of what your code is accomplishing then it's probably not designed well. And for another purely selfish reason, well-documented and well-structured code is far easier to dump onto someone else to maintain - thus freeing the original author to go create the next big thing. I rarely if ever have to stop what I'm doing to explain how my code was meant to work because it's blatantly obvious to anyone who can read English (even if they can't read C/C++/C# etc.). And one more reason is, frankly, my memory just isn't that good! I can't recall what I had for breakfast yesterday, much less what I was thinking when I wrote code a month or a year ago. Perhaps your memory is far better than mine, but because I document my intentions I can quickly pick up wherever I left off and make changes without having to first figure out what I was thinking when I wrote it.

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

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

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

If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.

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

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

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

保罗。

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

使用它的人想象力太少。

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

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

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

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

精通一门或精通许多门。

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

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

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