优秀的程序员讨厌编码

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

优秀的程序员是设计师

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

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

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

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

将XML存储在关系数据库中的CLOB中通常是一种可怕的逃避。它不仅在性能方面很糟糕，还将正确管理数据结构的责任从数据库架构师转移到应用程序程序员身上。

在编程中使用的进程越多，代码就会变得越糟糕

I have noticed something in my 8 or so years of programming, and it seems ridiculous. It's that the only way to get quality is to employ quality developers, and remove as much process and formality from them as you can. Unit testing, coding standards, code/peer reviews, etc only reduce quality, not increase it. It sounds crazy, because the opposite should be true (more unit testing should lead to better code, great coding standards should lead to more readable code, code reviews should improve the quality of code) but it's not.

我认为这可以归结为我们称之为“软件工程”的事实，而实际上它是设计而不是工程。

以下数字可以证实这一说法:

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.

请阅读文章，了解这些首字母缩写词的解释。

扩展方法是魔鬼的工作

Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).

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

I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.

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

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

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

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