it-swarm.cn

编写“好的代码”是什么意思?

this 问题中,我问作为一个不好的作家是否会妨碍您编写好的代码。许多答案都始于“这取决于您所指的好代码”。

看来“好代码”和“坏代码”是非常主观的。由于我有一个观点,所以可能与其他人的观点有很大不同。

那么编写“好的代码”意味着什么?什么是“好代码”?

41
gablin

一个好的编码员就像一个好的台球选手。

当您看到专业的台球选手时,乍一看可能不会对您印象深刻:“当然,他们把所有的球都塞进去了,但是他们只有简单的投篮机会!”这是因为,当台球运动员进行投篮时,她没有考虑哪个球会插入哪个口袋,而是在考虑母球将在哪里结束。为下一张照片做好准备需要大量的技巧和练习,但这也意味着它看起来很容易。

现在,将此隐喻带入代码中,一个好的编码器编写看起来很容易且直接的代码。 Brian Kernighan在他的书中的许多例子都遵循这种模式。 “技巧”的一部分来自于对问题及其解决方案的正确概念化。当我们对问题的理解不够充分时,我们更有可能使解决方案过于复杂,而我们将看不到统一的想法。

通过对问题进行适当的概念化,您可以获得所有其他信息:可读性,可维护性,效率和正确性。因为解决方案看起来如此简单,所以可能会减少评论,因为不需要额外的解释。好的编码人员还可以看到产品的长期前景,并据此形成其概念。

91
Macneil

WTF's per minute

原始


编辑:基本思想是不能将“代码质量”置于规则中,就像不能将“优良艺术”或“优良诗歌”置于规则中一样,因此您可以让计算机确定“是的,优良艺术”或“不,不好的诗歌”。当前,唯一的方法是查看该代码对其他人而言多么容易理解。

49
user1249

除了您能以多快的速度理解代码之外,实际上没有其他好的标准。通过在 简洁性 和可读性之间找到完美的折衷,可以使代码看起来不错。

“上面的每分钟WTF”是正确的,但这只是更普遍的规则的必然结果。 WTF越多,理解就越慢。

7
mojuba

您知道当...

  1. 顾客很高兴
  2. 同事们借用您的代码作为起点
  3. 刚刚告诉全新的家伙/女孩对您6个月前构建的系统进行修改,而他/她从没问过任何问题
  4. 您的老板要求您开发新的小部件以供团队使用
  5. 您看一下今天编写的代码,对自己说:“我希望两年前编写过这样的代码”

您如何衡量代码是否良好...

  • 响应时间是多少?
  • 它往返服务器多少次?
  • 您会亲自使用该应用程序还是觉得它笨拙?
  • 下次您会以相同的方式构建它吗?

好的代码应该在应该的时候工作。好的代码可以在需要时轻松地进行修改。好的代码可以重复使用以获利。

5

一个代码是

  1. 无错误

  2. 可重用

  3. 独立

  4. 不太复杂

  5. 有据可查

  6. 容易撞

被称为好代码。

一个好的程序可以完美地工作并且没有错误。但是,什么样的内部品质才能达到如此完美呢?这并不神秘,我们只需要偶尔提醒一下即可。无论您使用C/C++,C#,Java,Basic,Perl,COBOL还是ASM进行编码,所有好的编程都具有相同的历史悠久的品质:简单性,可读性,模块化,分层,设计,效率,优雅和净度效率,优雅和清晰度

来源: [〜#〜] msdn [〜#〜]

4
Chankey Pathak

这看起来很熟悉吗?

飞利浦给了我机会观看新产品的设计。随着事情的发展,我变得越来越不安,并开始将自己的顾虑告诉上司。我反复告诉他,这些设计不是“干净的”,并且应该以Dijkstra的设计漂亮的方式“美丽”。他认为这不是有用的评论。他提醒我,我们是工程师,而不是艺术家。在他看来,我只是表达自己的品味,他想知道我在做出判断时使用的标准。我无法告诉他!因为我无法解释违反了哪些原则,所以我的评论被忽略了,工作继续进行。意识到必须有一种方法来解释我的“品味”并为其提供动力后,我开始尝试找到一条将好设计与坏设计区分开的原理。工程师非常务实。他们可能会欣赏美丽,但他们寻求实用性。我试图找到一个解释“美丽”为何有用的原因。

请查看其余的 此处

3
mlvljr

除了自然的代码质量标准(最少复制/粘贴,没有意大利面条等)以外,好的工业代码应该看起来总是有些天真,太冗长,例如

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

相对于

Record r = cache.get(i++, false);
1
bobah

也许通过说明相反的问题的答案将有所帮助(此外,在这里获得 [〜#〜] xkcd [〜#〜] 是一个借口)。

alt text

好的代码是

  • 简单易懂
  • 易于维护
  • 不会仅尝试解决所有问题
  • 生活了很长一段时间而没有让开发人员寻找替代方案

例子包括

  • Apache Commons
  • 春季框架
  • 休眠框架
1
Gary Rowe

我只是选择“可维护”

所有代码都必须维护:无需使任务变得比必要的困难

如果任何读者不理解此简单要求或需要明确说明,则该读者不应编写代码...

1
gbn

好的代码对于每个人来说都是不同的,他们所使用的语言也会影响可能被认为是好的代码。通常,当我进入一个项目时,我会寻找以下内容:

  • 项目的组织方式?是否以干净的方式组织源文件,我是否可以不费吹灰之力找到代码?
  • 代码的组织方式?是否清楚记录了文件中代码的作用,例如通过使用文件头,还是通过使用驻留在其自己文件中的每个类?文件中是否有不再在应用程序中使用的功能?
  • 函数的组织方式?声明变量的位置是否有明确的模式,还是相当随机的模式?代码是否具有逻辑流程并避免不必要的控制结构?代码是否清楚地记录了一切,并在需要的地方进行了自我记录,并且注释清楚地表达了代码为什么和/或如何工作?

除此之外,应用程序的设计是否整体上有意义?驻留在应用程序中的代码可能是世界上最好的,但是如果应用程序的总体设计没有意义,使用它可能仍然很痛苦。

1
rjzii

让我不同意可读性。不,不完全是:好的代码应该是可读的,并且可以通过足够的注释轻松实现。

但是我考虑了两种WTF:一种是您想知道程序员是否比编程101更进一步的那种,另一种是您绝对不了解代码的一般性。某些代码起初看起来可能很奇怪,但实际上是解决难题的极富创造性的解决方案。第二个不应计入WTF-meter,可以通过注释来避免。

可读性强的代码可能非常非常慢。可读性较差的解决方案可以大大提高速度。 R是语言的一个很好的例子,这种情况经常是对的。人们喜欢尽可能地避免for循环。通常,尽管可读性较差,但我认为最快的代码会是更好的代码。也就是说,如果改进的幅度很大,并且插入了足够的注释以解释代码的作用。

更重要的是,内存管理在许多科学应用中都至关重要。可读性很强的代码在内存使用上往往很草率:创建的对象更多。在某些情况下,对内存的明智使用使代码再次变得不易读。但是,例如,如果您忙于处理千兆字节的DNA序列,那么内存是至关重要的因素。同样,无论可读性如何,我都认为占用较少内存的代码是更好的代码。

所以是的,可读性对于好的代码很重要。我知道Uwe Liggis的忠实人物:思想伤害和计算机便宜。但是在我的领域(统计基因组学)中,一周的计算时间和超过40 Gb的内存使用并不认为是异常。因此,将速度提高两倍,将内存减少一半所带来的价值,要比其可读性高得多。

1
Joris Meys

就我而言...我知道当一个在另一个项目上工作的同事出现并且能够跳入并理解我在做什么时,无需我遍历每段代码,我正在编写良好的代码并显示它在做什么。
代替他说:“请稍等,什么?!”他说:“哦,好吧,我明白你在那儿做了什么。”

好的代码也没有很多偷偷摸摸的解决方法或“ hacks”。排队的时候,当您编写它时,您还对自己说:“我知道这不是一个好方法,但是我现在只需要这样做。我会提醒我自己以后再改善...”

1
chiurox

“好的”代码有很多功能,但是最重要的恕我直言,是可读性和可维护性。

您的代码包含错误,将可能进行扩展和重新使用,以及应该在某些时候进行重构-即使它如果您重新访问它,很可能您一无所知,一开始到底是怎么做的,请帮自己一个忙,不要加任何障碍。

当然,请使用该效率更高的复杂算法,但是请确保您花了一些额外的时间来记录它,否则会使您的代码清晰且一致。

1
cjmUK