一个好的程序员的代码是什么样的？
我是一个业余程序员（用VBA开始，使excel更快），并一直在使用VB.NET / C＃.NET，并试图学习ADO.NET。 这是我的第一篇文章，我对这个问题的主观性质表示歉意。
一直让我感到沮丧的编程方面是“好”的样子？ 我不是一个专业，所以没有什么比较。 什么使得更好的程序员？ 是吗：
- 他们对某种语言的所有对象/类/方法有更好的理解？
- 他们的程序更有效率？
- 他们的程序devise在更好的文档，function名称的好select等方面要好得多？
换句话说，如果我要看一个专业程序员的代码，我会注意到他们的代码相对于我的第一个东西是什么？ 例如，我读Wrox出版社的“Professional ASP.NET”这样的书。 这本书是“世界级”的代码示例吗？ 这是巅峰吗？ 任何顶级的程序员都会看这个代码，并认为这是很好的代码吗？
下面的列表并不全面，但是这些是我在考虑你的问题时想到的。
-
好的代码组织良好。 数据和类的操作合在一起。 类之间没有多余的依赖关系。 它看起来不像“意大利面条”。
-
好的代码评论解释了为什么事情没有完成。 代码本身解释了所做的事情。 评论的需要应该是最小的。
-
良好的代码使用有意义的命名约定，但最短暂的对象。 一些东西的名字是关于何时以及如何使用该对象的信息。
-
好的代码经过了充分的testing。 testing作为代码的可执行规范和其使用示例。
-
好的代码不是“聪明的”。 它以直截了当的方式做事。
-
良好的代码是在小巧易读的计算单元中开发的。 这些单位在整个代码中被重复使用。
我还没有阅读，但我打算阅读这个主题的书是Robert C. Martin的Clean Code 。
你会注意到的第一件事是他们的代码遵循一致的编码风格 。 他们总是把他们的结构块写下来，并在适当的时候进行虔诚的评论。
第二件事你会注意到，他们的代码被分割成最多只有几十行的小的方法/函数。 他们也使用自描述方法名称，通常他们的代码是非常可读的。
第三件事你会注意到，在对代码搞混了之后，逻辑易于理解，易于修改，因此易于维护。
之后，您将需要一些软件devise技术方面的知识和经验，以了解他们构build代码体系结构的具体select。
关于书籍，我还没有看到很多书可以被认为是“世界级”的书。 在书中，他们主要是为了提供简单的例子，这些例子可能与解决非常简单的问题有关，但不能反映更复杂的情况。
引用福勒，summizing可读性：
任何傻瓜都可以编写计算机可以理解的代码。
好的程序员编写人类可以理解的代码。
“不过说。
就个人而言，我必须引用Tim Peters的“The Python of Zen” 。 它告诉Python程序员他们的代码应该是什么样的，但是我发现它基本上适用于所有的代码。
美丽胜过丑陋。
显式比隐式更好。
简单胜于复杂。
复杂比复杂好。
平面比嵌套更好。
稀疏比密集好。
可读性计数。
特例不足以打破规则。
虽然实用性胜过纯净。
错误不应该默默通过。
除非明确沉默。
面对歧义，拒绝猜测的诱惑。
应该有一个 – 最好只有一个 – 明显的方法来做到这一点。
尽pipe这种方式一开始可能并不明显，除非你是荷兰人。
现在比从未好。
虽然从来没有比现在更好。
如果实施很难解释，这是一个坏主意。
如果实施很容易解释，这可能是一个好主意。
命名空间是一个好主意 – 让我们做更多的！
代码是诗歌。
从这个逻辑的angular度开始，你可以得到很多合意的代码。 最重要的是，观察代码的读取远远超过了写入，因此为读者编写代码。 为读者重写，重命名，编辑和重构。
随之而来的是：
从代码创builddate开始，读者将在时间n。 为读者编写代码的回报是n的单调递增函数。 第一次看你的代码的读者用n == infinity表示。
换句话说，从编写代码到重新访问代码的时间差距越大，您就越感激您为读者编写代码所做的努力。 而且，任何你把代码交给代码的人都会从读者代码中得到很大的好处。
第二个必然结果：
不考虑读者的代码可能会不必要地难以理解或使用。 当读者的考虑降低到某个阈值以下时，阅读器从代码中获得的价值比通过重写代码获得的价值更less。 当发生这种情况时，先前的代码被丢弃，而且在重写过程中不幸的是重复了许多工作。
第三个必然结果：
推论二已知在代码不完整的恶性循环中多次重复，之后进行强制重写。
我已经编程了28年，我觉得这个问题很难回答。 对我来说，好的代码是一个完整的包。 代码是干净的书面，有意义的variables和方法名称。 它有很好的评论意见，代码的意图，不只是regurgitate你已经阅读的代码。 代码在不浪费资源的情况下以一种有效的方式实现它应该做的事情。 它还必须着眼于可维护性。
但底线是对不同的人意味着不同的东西。 我可能将其标签为别人可能讨厌的好代码。 良好的代码将有一些共同的特点，我认为我已经确定了上面。
你可以做的最好的事情是暴露自己的代码。 看看别人的代码。 开源项目是一个很好的来源。 你会发现很好的代码和糟糕的代码。 你越是看它，你就越能认出你认为是好代码和坏代码。
最终你会成为你自己的法官。 当你发现你喜欢采用的风格和技巧时，随着时间的推移，你会想出自己的风格，而且随着时间的推移会发生变化。 这里没有人能挥动魔杖说什么是好的，别的什么坏的。
阅读“代码完成”一书。 这就解释了很多关于如何构造代码的想法以及这样做的原因。 阅读它应该缩短你的时间来获得必要的经验，从坏的方面讲好。
现在我已经编写了近10年的编程，并与其他人一起工作，我可以毫无偏见地说，一个好的程序员和一个普通的程序员代码是没有区别的
所有程序员在合格的水平：
- 正确评论
- 结构有效
- 文件干净
我曾经无意中听到一位同事说：“ 我一直很有逻辑和理性，我觉得这就是为什么我喜欢发展 ”
在我看来，这是一个普通程序员的头脑。 一个在规则和逻辑方面看世界的人，在devise和编写程序时最终服从这些规则。
专家程序员，了解规则，也是他们的上下文。 这最终导致他们提出新的想法和实现，这是专家程序员的标志。 编程最终是一种艺术forms。
简单地说， 一个好的程序员的代码可以被阅读和理解。
在我看来，一个好的程序员的代码是语言不可知的 ; 写得很好的代码可以在很短的时间内以最less的思考读取和理解，而不pipe使用的编程语言如何。 无论代码是使用Java，Python，C ++还是Haskell，编写良好的代码对于那些甚至不用该特定语言编程的人都是可以理解的。
易于阅读的代码的一些特点是，名字方法，缺乏“技巧”和复杂的“优化”，类devise良好，仅举几例。 正如其他人所说， 编码风格是一致的，简洁而直接的 。
例如，有一天，我正在看TinyMCE的代码来回答堆栈溢出的一个问题。 它是用JavaScript编写的，这是一种我很less使用的语言。 然而，由于代码的风格和意见，以及代码本身的结构，这是相当可以理解的，我可以在几分钟内浏览代码。
美好的代码在阅读好的程序员代码方面对我来说是一个令人大开眼界的书。 它有许多由各种编程语言的编程人员编写的文章。 然而，当我阅读它时，我甚至可以理解作者在代码中写的是什么，尽pipe我甚至从来没有用这种特定的语言编程。
也许我们应该记住的是， 编程也是关于沟通的，不仅是计算机，而且是沟通，所以好的程序员的代码几乎就像一本写得很好的书，可以向读者传达想要传达的想法。
- 易于阅读
- 容易写
- 易于维护
一切都是花丝
好的代码应该很容易理解。
应该好好评论一下。
困难的部分应该更好地评论。
好的代码是可读的。 在第一次读懂一个好的专业程序员写的代码时，你不难理解代码在做什么。
只是想在你的代码中添加我的2美分…注释 – 而你的代码本身 – 通常应该说你的代码做了什么，现在怎么做。 一旦你有'客户'代码的概念，这是代码调用其他代码（最简单的例子是调用方法的代码），你应该始终最担心的是从“客户”的angular度来理解你的代码。 随着代码的增长，你会发现这是……呃，好。
很多关于优秀代码的其他内容是关于你将会做出的精神上的跳跃（当然，如果你注意的话）… 99％的人现在要做更多的工作来为你节省大量的时间以后工作，可重用。 而且还要做正确的事情：我几乎总是想用另一种方式来运行，而不是使用正则expression式，但是每当我进入它们时，我都明白为什么每个人都用我工作的每种语言来使用它们（它们是深奥的，但是工作，可能不会更好）。
关于是否看书，我绝对不会以我的经验。 查看API和框架，代码约定和其他人的代码，并使用自己的直觉，并试图理解为什么东西是这样的，事物的含义是什么。 书中的代码几乎从来没有做的事情是计划外，这是错误检查的全部。 这只有当有人给你发邮件时才会有回报，并说：“我得到了321错误”，而不是“嘿，应用程序坏了，哟”。
良好的代码是从程序员的angular度和用户的angular度来考虑未来的。
相反，重复其他人的伟大build议，我会build议你阅读史蒂夫·麦康奈尔的“ 代码完成 ”一书
本质上它是一本充满了function和风格编程最佳实践的书。
[纯粹主观的答案]
对我来说，好的代码就像一幅画一样是一种艺术forms。 我可以进一步说，它实际上是一个包含字符，颜色，代码“forms”或“结构”的graphics，而且所有这些都是可读/可执行的。 可读性，结构（即列，缩进，甚至相同长度的variables名称），颜色（类名，variables名，注释等）的组合使我所喜欢看到的“美丽”图片让我感到自豪或非常厌恶我自己的代码。
（如前所述，非常主观的答案，对不起我的英文。）
我第二次推荐Bob Martin的“Clean Code”。
“美丽守则”几年前备受好评。
任何麦康奈尔的书都值得一读。
也许“实用程序员”也会有所帮助。
％
这在福勒的书“重构”中得到了很好的回答，这是他在整本书中所描述的所有“气味”的缺失。
我还没有看到“专业ASP.NET”，但如果比好的更好，我会感到惊讶。 看到这个问题的一些书，真的很好的代码。 （这当然是不一样的，但是被接受的答案很难被打败。）
这似乎是（应该）一个常见问题。 最近有一篇关于漂亮代码的ACM文章 。 似乎有很多强调易于阅读/理解。 我想用“易于阅读/领域专家了解”的限定词。 真正优秀的程序员倾向于使用最好的algorithm（而不是幼稚容易理解的O（n ^ 2）algorithm）对于任何给定的问题，这可能很难遵循，如果你不熟悉algorithm，即使好程序员给出了algorithm的参考。
没有人是完美的，包括优秀的程序员，但他们的代码倾向于争取 ：
- 经过validation的algorithm的正确性和效率（而不是天真和adhoc黑客）
- 清晰度（针对非平凡algorithm的意图评论）
- 完整性涵盖基础（编码约定，版本控制，文档，unit testing等）
- 简洁（干）
- 健壮性（适应任意input和中断变更请求）
我第二次推荐伯伯叔叔的“干净的代码”。 但你可能希望看看http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091，因为我认为这处理你的具体问题好一点。; 良好的代码应该跳出页面，并告诉你它是什么/它是如何工作的。
杰夫·阿特伍德写了一篇关于打字员如何首先参考的好文章： http : //www.codinghorror.com/blog/archives/001188.html
作为打字员，你总是需要在工作中保持优雅，结构和适当的“语法”是非常重要的。 现在将其转换为“编程”types会得到相同的结果。
结构体
注释
地区
我是一个软件工程师，这意味着在我的教育期间，我遇到了很多不同的语言，但是我的编程总是“感觉”一样，就像我在fekberg.wordpress.com上写的一样，我有一个“特殊”的input方式。
现在编写不同的应用程序和不同的语言，如Java，C＃，汇编，C ++，C我已经到了我喜欢的写作“标准”。
我把所有东西都看作“盒子”或地区，每个地区都有解释评论。 一个区域可能是“类人”，在这个区域内，我有一些属性的方法，我可以称之为“访问方法”，或者每个属性和区域都有自己的解释性注释。
这是非常重要的，我总是看到我的代码，作为一个API的一部分，当创build一个API结构和优雅是非常重要的。
想想这个。 另外请阅读我关于Communication issues when adapting outsourcing文章， Communication issues when adapting outsourcing ，粗略解释，代码可以冲突的程度如何，Enterpret如你所愿： http : //fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-外包/
好的代码很容易理解，易于维护，易于添加。 理想情况下，在不牺牲其他指标的情况下，也尽可能高效。
对我来说，伟大的代码是简单易懂而又复杂的东西。 那些让你走的东西，“哇，当然，我为什么不这么想呢？” 真正好的代码并不难理解，它只是简单地直接解决手头上的问题（或者recursion的方式，如果更简单的话）。
好的代码就是你知道这个方法从名字中做些什么的地方。 错误的代码是你必须弄清楚代码的作用，弄清楚名字。
好的代码就是在你阅读它的地方，你可以在不多的时间内理解它在做什么。 糟糕的代码就是你最终看着它试图解决它的问题。
好的代码有这样一种命名的方式，以使无用的评论。
好的代码往往很短。
好的代码可以被重复使用来做其他任何事情，因为它不依赖于与其目的无关的东西。
良好的代码通常是一组简单的工具来完成简单的工作（以组织良好的方式来完成更复杂的工作）。 不好的代码往往是巨大的多用途的工具，容易打破和难以使用。
代码是程序员技能和思维的反映。 好的程序员总是关注未来 – 当需求或环境与现在不一样时，代码将如何运作。 它将如何scalabale？ 当我不是维护这个代码的时候会有多方便？ 代码的可重用性如何，以便其他人做类似的东西可以重用代码，而不是再次写入。 当别人试图理解我写的代码的时候。
当一个程序员有这样的想法时，所有其他的东西都很好地落实到位。
注意：许多程序员一段时间都在处理代码库，通常程序员没有特定的代码库名称。 因此，良好的代码是公司所有标准和员工素质的反映。
（我使用下面的“他”，因为这是我渴望成为的人，有时成功）。
我相信一个好的程序员哲学的核心是他总是在想：“我为自己编写代码，当我忘记了这个任务，为什么我正在研究这个任务，有什么风险，甚至是如何代码本来是可行的。“
因此，他的代码必须：
- 工作（无论代码的错误答案有多快，在现实世界中都没有部分功劳）。
- 解释他是如何知道这个代码的作品。 这是一个文档（javadoc是我的首选工具），exception处理和testing代码的组合。 在一个非常真实的意义上，我相信，为了行，testing代码比function代码更有价值，如果没有其他原因，它解释“这个代码的作品，这是应该如何使用，这就是为什么我应该得到有偿“。
- 保持。 死代码是一场噩梦。 遗留代码维护是一件苦差事，但必须完成（并记住，它离开你的桌子的那一刻是“遗留的”）。
另一方面，我相信优秀的程序员不应该做这些事情：
- 关注格式化。 有很多IDE，编辑器和漂亮的打印机，可以将代码格式化为您认为合适的标准或个人偏好。 我使用Netbeans，我设置了一次格式化选项，并且偶尔点击alt-shift-F。 决定如何让代码看起来，设置你的环境，并让工具做的咕噜工作。
- 以牺牲人际交stream为代价，忽视命名约定。 如果一个命名约定引导你沿着命名你的类“IElephantProviderSupportAbstractManagerSupport”而不是“Zookeeper”的路线，那么在你使下一个人变得更难之前，改变标准。
- 忘记他是一个真正的人类团队。
- 忘记编码错误的主要来源是现在坐在他的键盘上。 如果有错误或错误，他应该先看看自己。
- 忘记随处可见。 他现在为了使未来的读者更容易访问他的代码所做的任何工作，几乎肯定会直接使他受益（因为谁是第一个被要求查看他的代码的人？）。
- 有用
- 它有unit testing，certificate它的工作
剩下的就是结冰…
- 最好的代码有一定的优雅，你一看到就认出来。
- 它看起来精心制作，注意细节。 这显然是由一个有技能的人创造出来的，并且有一个关于它的艺术 – 你可以说它看起来雕刻和打磨，而不是粗糙和准备。
- 这是一致的，读取容易。
- 它被分成小的，高度凝聚力的function，每个function都做一件事，做得很好。
- 它是最小的耦合，这意味着依赖性很less，并严格控制，通常由…
- 函数和类依赖于抽象而不是实现。
具有讽刺意味的是，程序员越好，他/她就越不可缺less，因为任何人都可以更好地维护代码（正如Eran Galperin普遍认可的那样）。
我的经验告诉相反的也是如此。 程序员 越是越难维护他/她的代码，他/她就越不可或缺 ，因为没有其他人能够理解所产生的谜语。
我有一个很好的例子：
阅读GWT（谷歌网站takeit）源代码，你会看到每个傻瓜都明白它（一些英文书比这个代码更难读）。
