我是一名业余程序员（从 VBA 开始以使 excel 更快）并且一直在使用 VB.NET / C#.NET 并正在尝试学习 ADO.NET。
一直让我感到沮丧的编程方面是“好”是什么样的？我不是专业人士，所以没什么可比较的。是什么造就了一个更好的程序员？ 是吗：
换句话说，如果我要查看专业程序员的代码，我首先会注意到他们的代码相对于我的代码是什么？例如，我阅读了 Wrox 出版社的“Professional ASP.NET”之类的书。那本书中的代码示例是“世界级”吗？那是巅峰吗？任何顶级程序员会不会看到该代码并认为它是好代码？
【问题讨论】：
标签： coding-style
下面的列表并不全面，但这些是我在考虑您的问题时想到的。
好的代码是组织良好的。类中的数据和操作结合在一起。类之间没有无关的依赖关系。它看起来不像“意大利面”。
好的代码 cmets 解释了为什么要做的事情而不是做了什么。代码本身解释了做了什么。对 cmets 的需求应该是最小的。
好的代码对除了最短暂的对象之外的所有对象都使用有意义的命名约定。事物的名称是关于何时以及如何使用该对象的信息。
好的代码是经过良好测试的。测试作为代码的可执行规范及其使用示例。
好的代码不是“聪明”的。它以简单明了的方式做事。
好的代码是在小的、易于阅读的计算单元中开发的。这些单元在整个代码中重复使用。
我还没有读过，但我打算读的关于这个主题的书是 Robert C. Martin 的Clean Code。
【讨论】：
您会注意到的第一件事是他们的代码遵循一致的coding-style。他们总是写同样的结构块，虔诚地缩进并在适当的地方发表评论。
您会注意到的第二件事是，他们的代码被分割成小的方法/函数，最多不超过几十行。他们还使用自我描述的方法名称，并且通常他们的代码非常易读。
在稍微弄乱代码之后，您会注意到的第三件事是逻辑易于遵循、易于修改 - 因此易于维护。
之后，您将需要一些软件设计技术方面的知识和经验，以了解他们在构建代码架构时所采取的具体选择。
关于书籍，我还没有看到很多书籍可以将代码视为“世界级”。在书中，他们主要尝试提供简单的示例，这些示例可能与解决非常简单的问题相关，但不能反映更复杂的情况。
【讨论】：
引用 Fowler，总结可读性：
任何傻瓜都可以编写计算机可以理解的代码。
优秀的程序员编写人类可以理解的代码。
'不用说了。
【讨论】：
就个人而言，我将不得不引用 Tim Peters 的“Python 之禅”。它告诉 Python 程序员他们的代码应该是什么样子，但我发现它基本上适用于所有代码。
美丽胜于丑陋。
显式胜于 隐含的。
简单胜于复杂。
复杂胜于复杂 比复杂。
扁平比嵌套更好。
稀疏是 比密集更好。
可读性很重要。
特殊情况 还不够特别，不能打破规则。
虽然实用 胜过纯洁。
错误永远不应该悄无声息地过去。
除非 明确沉默。
面对模棱两可，拒绝 猜测的诱惑。
应该有一个 - 最好只有 一种 --obvious 方式。
虽然这种方式可能并不明显 一开始除非你是荷兰人。
现在总比没有好。
虽然从来没有比现在更好正确。
如果 实现很难解释，这是个坏主意。
实现很容易解释，这可能是个好主意。
命名空间是一个很棒的主意——让我们做更多的事情！
【讨论】：
代码就是诗。
从这个逻辑点开始，您可以推导出许多理想的代码品质。最重要的是，观察代码的阅读量远远超过编写量，因此为读者编写代码。为读者重写、重命名、编辑和重构。
推论的后续：
从代码创建之日起的 n 时间，读者将是您。为读者编写代码的回报是 n 的单调递增函数。 n == infinity 表示第一次查看您的代码的读者。
换句话说，从您编写代码到重新访问代码的时间间隔越大，您就越会感谢您为读者编写的努力。此外，您将代码交给任何人都将从以读者为首要考虑编写的代码中受益匪浅。
第二个推论：
在没有考虑到读者的情况下编写的代码可能会不必要地难以理解或使用。当读者的考虑下降到某个阈值以下时，读者从代码中获得的价值少于通过重写代码获得的价值。发生这种情况时，之前的代码被丢弃，可悲的是，在重写过程中重复了很多工作。
第三个推论：
众所周知，推论二会在记录不良的代码的恶性循环中重复多次，然后强制重写。
【讨论】：
我已经编程了 28 年，我发现这是一个很难回答的问题。对我来说，好的代码是一个完整的包。代码写得很干净，带有有意义的变量和方法名称。它有很好的 cmets 注释代码的意图，而不仅仅是反刍您已经阅读的代码。该代码以一种有效的方式完成了它应该做的事情，而不会浪费资源。它的编写还必须着眼于可维护性。
但底线是它对不同的人意味着不同的东西。我可能将其标记为别人可能讨厌的好代码。好的代码会有一些我认为我在上面已经确定的共同特征。
您能做的最好的事情就是让自己接触代码。看看别人的代码。开源项目是一个很好的来源。你会发现好的代码和坏的代码。你看的越多，你就越能识别出你认为是好的代码和坏的代码。
最终，您将成为自己的法官。当你找到你喜欢的风格和技术时，随着时间的推移，你会想出自己的风格，并且会随着时间的推移而改变。这里没有人可以挥动魔杖说什么是好的，什么是坏的。
【讨论】：
阅读《代码完成》这本书。这解释了很多关于如何构建代码的想法以及这样做的原因。阅读它应该可以缩短您获得分辨好坏所需的经验的时间。
【讨论】：
我自己已经编程了近 10 年，并且与其他人一起工作过
所有合格的程序员：
我曾经无意中听到一位同事说“我一直非常有逻辑和理性。我认为这就是我喜欢开发的原因”
在我看来，这是一个普通程序员的想法。从规则和逻辑的角度看待世界并最终在设计和编写程序时遵守这些规则的人。
专家级程序员了解规则，也了解它们的上下文。这最终导致他们提出新的想法和实现，这是专家程序员的标志。 编程最终是一种艺术形式。
【讨论】：
简而言之，优秀的程序员的代码可以被阅读和理解。
在我看来，优秀程序员的代码与语言无关；无论使用何种编程语言，编写良好的代码都可以在短时间内以最少的思考被阅读和理解。无论代码是用 Java、Python、C++ 还是 Haskell 编写的，编写良好的代码都可以被甚至不使用该特定语言编程的人理解。
易于阅读的代码的一些特征是，命名良好的方法，没有“技巧”和复杂的“优化”，类设计良好，仅举几例。正如其他人所提到的，编码风格始终如一、简洁明了。
例如，前几天，我在查看 TinyMCE 的代码以回答 Stack Overflow 上的一个问题。它是用 JavaScript 编写的，这是一种我几乎没有使用过的语言。然而，由于编码风格和包含的 cmets，以及代码本身的结构，它是相当容易理解的，我能够在几分钟内浏览代码。
在阅读优秀程序员的代码方面，一本让我大开眼界的书是Beautiful Code。它有许多由各种编程项目的作者用各种编程语言撰写的文章。然而，当我阅读它时，我可以理解作者在他的代码中所写的内容，尽管事实上我从未使用过那种特定的语言进行编程。
也许我们应该记住的是，编程也是关于交流的，不仅是对计算机，对人也是如此，所以好的程序员的代码就像一本写得很好的书，可以交流向读者介绍它想要传达的想法。
【讨论】：
其他的都是花丝
【讨论】：
好的代码应该易于理解。
应该好好评论。
困难的部分应该得到更好的评论。
【讨论】：
好的代码是可读的。在第一次通读由优秀的专业程序员编写的代码时，您将毫不费力地理解代码在做什么。
【讨论】：
与其重复其他人的好建议，我会建议您阅读史蒂夫·麦康奈尔（Steve McConnell）的书Code Complete
本质上，它是一本囊括了功能和风格的编程最佳实践的书。
【讨论】：
[纯主观回答]
对我来说，好的代码是一种艺术形式，就像一幅画。我可能会更进一步说，它实际上是一幅包含字符、颜色、代码“形式”或“结构”的绘图，并且所有这些都非常可读/高性能。可读性、结构（即列、缩进，甚至相同长度的变量名！）、颜色（类名、变量名、cmets 等）的组合都使我喜欢看到的“美丽”图片可以让我对自己的代码感到非常自豪或非常厌恶。
（如前所述，非常主观的答案。对不起我的英语。）
【讨论】：
我赞同 Bob Martin 的“清洁代码”的建议。
《美丽密码》在几年前就广受好评。
麦康奈尔的任何书都值得一读。
也许“实用程序员”也会有所帮助。
%
【讨论】：
只是想在您的代码中添加我的 2 美分... cmets - 以及您的代码本身，通常 - 应该说明您的代码做什么，现在它是如何做的。一旦你有了“客户端”代码的概念，即调用其他代码的代码（最简单的例子是调用方法的代码），你应该总是最担心从“客户端”的角度理解你的代码。随着代码的增长，您会发现这是……嗯，很好。
很多关于优秀代码的其他内容是关于你将做出的精神飞跃（当然，如果你注意的话）......其中 99% 与现在做更多的工作以节省你的时间有关大量的工作之后，以及可重用性。还有做正确的事：我几乎总是想以另一种方式运行而不是使用正则表达式，但每次我进入它们时，我都会明白为什么每个人在我工作的每一种语言中都使用它们（它们很深奥，但很有效，可能再好不过了）。
关于是否看书，根据我的经验，我会说绝对不会。查看 API 和框架、代码约定和其他人的代码，并运用自己的直觉，尝试理解事物为何如此，以及事物的含义是什么。书中的代码几乎从不做的事情是为计划外的事情做计划，这就是错误检查的全部内容。只有当有人向您发送电子邮件并说“我收到错误 321”而不是“嘿，应用程序坏了，哟”时，这才会有回报。
无论是从程序员的角度还是用户的角度，编写好的代码都是着眼于未来。
【讨论】：
这在 Fowler 的《重构》一书中得到了很好的回答，他在整本书中描述的所有“味道”都没有。
【讨论】：
我还没有看过“专业 ASP.NET”，但如果它比 OK 更好，我会感到惊讶。请参阅this question 了解一些代码非常好的书籍。 （当然，它会有所不同，但公认的答案很难被击败。）
【讨论】：
这似乎是（应该是）一个常见问题解答。最近有an ACM article关于漂亮的代码。似乎有很多强调易于阅读/理解。我会用“领域专家易于阅读/理解”来限定它。对于任何给定的问题，真正优秀的程序员倾向于使用最好的算法（而不是简单易懂的 O(n^2) 算法），如果你不熟悉算法，即使好的算法也很难理解。程序员给出了算法的参考。
没有人是完美的，包括优秀的程序员，但他们的代码倾向于努力：
【讨论】：
我第二次推荐鲍勃叔叔的“干净代码”。但是您可能希望查看http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091，因为我认为这可以更好地解决您的具体问题。好的代码应该跳出页面，告诉你它做什么/它是如何工作的。
【讨论】：
Jeff Atwood 写了一篇关于编码员如何成为打字员的第一参考的好文章： http://www.codinghorror.com/blog/archives/001188.html
作为一名打字员，您的工作总是需要优雅，具有结构和适当的“语法”非常重要。现在将其转换为“编程”类型将获得相同的结果。
结构
评论
地区
我是一名软件工程师，这意味着在我的教育过程中，我遇到了许多不同的语言，但我的编程总是“感觉”相同，就像我在 fekberg.wordpress.com 上的写作一样，我有一种“特殊”的方式用于打字。
现在用不同的语言编写不同的应用程序，例如 Java、C#、Assembler、C++、C，我已经达到了我喜欢的写作“标准”。
我将所有内容都视为“框”或区域，每个区域都有解释性评论。一个区域可能是“类人”，在这个区域内我有几个属性方法，我可以称之为“访问方法”等，每个属性和区域都有自己的解释性评论。
这非常重要，我总是将我的代码视为“成为 api 的一部分”，在创建 API 结构和优雅时非常很重要。
考虑一下。还可以阅读我在Communication issues when adapting outsourcing 上的论文，它粗略地解释了糟糕的代码会如何发生冲突，随意输入：http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/
【讨论】：
好的代码易于理解、易于维护和易于添加。理想情况下，在不牺牲其他指标的情况下也尽可能高效。
【讨论】：
对我来说，伟大的代码是易于掌握但复杂的东西。让你去的东西，“哇，当然，我为什么不这么想呢？”。真正好的代码并不难理解，它只是以直接的方式（或递归方式，如果更简单的话）解决手头的问题。
【讨论】：
好的代码是您从名称中知道方法的作用。糟糕的代码是你必须弄清楚代码的作用，才能理解名称的地方。
好的代码是如果你阅读它，你可以在不比阅读它花费更多的时间里理解它在做什么。糟糕的代码是您最终查看它的地方，试图解决它确实如此。
好的代码的命名方式使得琐碎的 cmets 变得不必要。
好的代码往往很短。
好的代码可以在其他地方重复使用，因为它不依赖与目的无关的东西。
好的代码通常是一组用于完成简单工作的简单工具（以组织良好的方式组合在一起以完成更复杂的工作）。糟糕的代码往往是庞大的多用途工具，易于破解且难以使用。
【讨论】：
代码反映了程序员的技能和思维方式。优秀的程序员总是着眼于未来——当需求或环境与今天不完全一样时，代码将如何运行。它将有多大的可扩展性？当我不是维护此代码的人时，它会有多方便？代码的可重用性如何，以便做类似事情的其他人可以重用代码而无需再次编写。当别人试图理解我写的代码时怎么办。
当程序员有这种心态时，所有其他东西都会很好地到位。
注意：随着时间的推移，许多程序员都会编写代码库，并且通常没有特定的代码库指定给程序员。因此，好的代码是公司所有标准和员工素质的反映。
【讨论】：
（我在下面使用“他”，因为这是我渴望成为的人，有时会成功）。
我相信一个优秀程序员哲学的核心是他总是在想“我在将来为自己编码时，我会忘记所有关于这个任务，我为什么要工作，有什么风险和甚至这段代码应该如何工作。”
因此，他的代码必须：
另一方面，我认为优秀的程序员永远不应该做这些事情：
【讨论】：
剩下的就是锦上添花……
【讨论】：
【讨论】：
具有讽刺意味的是，程序员越好他/她变得不可或缺，因为所生成的代码更容易被任何人维护（正如 Eran Galperin 普遍同意的那样）。
我的经验告诉我相反的情况也是如此。 程序员越差，他/她的代码就越更难维护，所以他/她变得更不可或缺，因为没有其他灵魂可以理解产生的谜语。
【讨论】：
我有一个很好的例子：
阅读GWT（google web takeit）源代码，你会发现每个傻瓜都懂（有些英文书比这段代码更难读）。
【讨论】：