编写“好的代码”是什么意思？[关闭]
Answers:
一个好的编码员就像一个好的台球选手。
当您看到专业的台球选手时，乍一看可能不会对您印象深刻：“当然，他们把所有的球都塞进去了，但是他们只有简单的投篮机会！” 这是因为，当台球运动员进行投篮时，她没有考虑哪个球会插入哪个口袋，而是在考虑母球的结局。为下一张照片做好准备需要大量的技巧和实践，但这也意味着它看起来很容易。
现在，将这种隐喻带入代码中，一个好的编码器可以编写看起来很容易且直接的代码。布赖恩·克尼根（Brian Kernighan）在其著作中的许多示例都遵循这种模式。“技巧”的一部分是对问题及其解决方案的正确概念化。当我们对问题的理解不够充分时，我们更有可能使解决方案过于复杂，而我们将看不到统一的想法。
通过对问题进行适当的概念化，您可以获得所有其他信息：可读性，可维护性，效率和正确性。因为解决方案看起来如此简单，所以可能会减少评论，因为不需要额外的解释。好的编码人员还可以看到产品的长期前景，并据此形成其概念。
（原始）
编辑：基本思想是不能将“代码质量”置于规则中，就像不能将“优良艺术”或“优良诗歌”置于规则中一样，因此您可以让计算机确定“是的，优良艺术”或“不，不好的诗歌”。当前，唯一的方法是查看该代码对其他人而言多么容易理解。
除了您能以多快的速度理解代码之外，实际上没有其他好的标准。通过在简洁性和可读性之间找到完美的折衷，可以使代码看起来不错。
“每分钟WTF”（上面）是正确的，但这只是更普遍的规则的必然结果。WTF越多，理解就越慢。
RemoveCustomer方法实际上去除了角质层而不用拧紧。您可以花几个小时使它看起来很漂亮，但这并不意味着它实际上可以工作。我要说的是，“您能以多快的速度理解代码”并不是“好的代码”的唯一标准。
您知道当...
- 顾客很高兴
- 同事们借用您的代码作为起点
- 刚刚告诉全新的家伙/女孩对您6个月前构建的系统进行修改，而他/她从未曾问过您一个问题
- 您的老板要求您开发新的小部件以供团队使用
- 您看一下今天编写的代码，对自己说：“我希望两年前已经编写了这样的代码”
您如何衡量代码是否良好...
- 响应时间是多少？
- 它往返服务器多少次？
- 您会亲自使用该应用程序还是觉得它笨拙？
- 下次您会以相同的方式构建它吗？
好的代码应该在应该的时候工作。好的代码可以在需要时轻松地进行修改。好的代码可以重复使用以获利。
一个代码是
无错误
可重用
独立
不太复杂
有据可查
容易撞
被称为好代码。
一个好的程序可以完美地工作并且没有错误。但是，什么样的内部品质才能达到如此完美呢？这并不神秘，我们只需要偶尔提醒一下即可。无论您使用C / C ++，C＃，Java，Basic，Perl，COBOL还是ASM进行编码，所有好的编程都具有相同的历史悠久的品质：简单性，可读性，模块化，分层，设计，效率，优雅和清晰度效率，优雅和清晰度
来源：MSDN
这看起来很熟悉吗？
飞利浦给了我机会观看新产品的设计。随着事情的发展，我变得越来越不安，并开始向上司倾诉我的疑虑。我反复告诉他，设计不是“干净的”，并且应该以Dijkstra的设计漂亮的方式“美丽”。他认为这不是有用的评论。他提醒我，我们是工程师，而不是艺术家。在他看来，我只是表达自己的品味，他想知道我在做出判断时使用的标准。我无法告诉他！因为我无法解释违反了哪些原则，所以我的评论被忽略了，工作继续进行。意识到必须有一种方法来解释我的“品味”并为其提供动力，我开始尝试找到一种将好的设计与不好的设计区分开的原理。工程师非常务实。他们可能会欣赏美丽，但他们寻求实用性。我试图找到一个解释“美丽”为何有用的原因。
请在这里查看其余内容。
除了自然的代码质量标准（最少的复制/粘贴，没有意大利面条等）之外，好的工业代码应该看起来总是有些天真，太冗长，例如
int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;
相对于
Record r = cache.get(i++, false);
do_not_create = false说“ false作为do_not_create参数传递，以便将其创建”还是“ false作为do_create参数传递，而不将其创建”？在一种您可以使用参数名称的语言中，我更喜欢cache.get (key:i, create: false); i += 1;。
好的代码对于每个人来说都是不同的，他们所使用的语言也会影响可能被认为是好的代码。通常，当我进入一个项目时，我会寻找以下内容：
- 项目如何组织？源文件是否组织得井井有条，我是否可以不费吹灰之力找到代码？
- 代码如何组织？是否清楚地记录了文件中的代码是做什么的，例如通过使用文件头或通过使用驻留在其自己文件中的每个类？文件中是否有不再在应用程序中使用的功能？
- 职能如何组织？声明变量的位置是否有明确的模式，还是相当随机的模式？代码是否具有逻辑流程并避免不必要的控制结构？代码是否清楚地记录了一切，并在需要的地方进行了自我记录，注释清楚地表达了代码为什么和/或如何工作？
除此之外，应用程序的设计是否整体上有意义？驻留在应用程序中的代码可能是世界上最好的，但是如果应用程序的整体设计没有意义，则使用它仍然很痛苦。
让我不同意可读性。不，不完全是：好的代码应该是可读的，并且可以通过足够的注释轻松实现。
但是我考虑了两种WTF：一种是您想知道程序员是否比编程101更进一步的那种，另一种是您绝对不了解代码的一般性。一开始有些代码看起来很奇怪，但实际上是解决难题的极富创造性的解决方案。第二个不应计入WTF-meter，可以通过注释来避免。
可读性强的代码可能非常非常慢。可读性较差的解决方案可以大大提高速度。R是语言的一个很好的例子，这种情况经常是对的。人们喜欢尽可能地避免for循环。通常，尽管可读性较差，但我认为最快的代码会是更好的代码。也就是说，如果改进的幅度很大，并且插入了足够的注释以解释代码的作用。
更重要的是，内存管理在许多科学应用中都至关重要。可读性很强的代码在内存使用上往往有些草率：创建了更多对象。在某些情况下，对内存的明智使用使代码再次变得不易读。但是，例如，如果您忙于处理千兆字节的DNA序列，那么内存是至关重要的因素。同样，无论可读性如何，我都认为占用较少内存的代码是更好的代码。
所以是的，可读性对于好的代码很重要。我知道Uwe Liggis的忠实人物：思想伤害和计算机便宜。但是在我的领域（统计基因组学）中，一周的计算时间和超过40 Gb的内存使用并不认为是异常。因此，将速度提高两倍，将内存减少一半所带来的价值，要比其可读性高得多。