您见过的最好的开源代码是什么?[关闭]


19

开源的部分价值是为入门新平台或新语言的人们提供出色的示例代码。

您遇到的最好的开源代码是什么,为什么您喜欢您的选择?任何语言都可以,但是我对您可以指出的Objective-C的最佳示例特别感兴趣。

显然,这是一个开放式的问题,因此我将让问题开放一段时间,看看我们会得到什么样的答案。

谢谢!

编辑:对于“最佳”,我正在考虑遵循给定语言或平台中的惯用法的代码,以及使代码“专业”的部分-好的文档,测试套件等。代码简洁,但是不太聪明而不是非常简洁或健谈的代码。


4
对“最佳”有什么特别的定义吗?

您的问题有点广泛。也许您可以对其进行更具体的编辑,然后定义“最佳”对您而言意味着什么。最佳的用户界面,最佳的桌面/网络/电话应用程序,最佳的并发性,最佳的视觉吸引力代码?
Walter

+1是一个好问题。我建议您将其修剪为某些特定的语言/技术。坦率地说,将Linux的C与数据库驱动的Java进行比较是一个不一致的想法。
Fanatic23 2011年

如果您将说明内容编辑进去,这对其他人阅读该问题将非常有帮助。:)
Michael K

Answers:


14

我不得不说,多年来看过一些开源代码后,我对所有这些都感到非常失望。

对我来说,主要的烦恼是评论很少,通常唯一的评论是一些冗长而合法的版权声明。

linux内核是一个示例,其中文件经常甚至没有在注释中说出它们服务的目的(例如XYZ驱动程序至少会告诉我我在正确的位置)。

我来自商业和国防编程领域,在这些领域中,编码标准要求明智的可理解注释,不仅是要说明代码单元的功能,而且在整个代码中,必须有描述算法,方法,特殊性,hacks /聪明事物的注释块。 ,所有这些使以后的人都可以快速查看并找出正在执行的操作,而不用费力地遍历实际代码。

可能的道理是:告诉我您在做什么,不要让我弄清楚。

我没有找到任何能做到这一点的开源代码。至于将开源作为学习良好编码实践的一种方式,我的黄疸建议是:不要。


我同意开放源代码项目的评论往往很少,文档也很少。但是他们都是志愿者。通常很难激发志愿者去做不愉快的事情,而没有他们想要的回报(状态,社交,成就伟大的事情或做自己喜欢的事情)。

@ pierre303-我创建并维护了NoRMproject.org,我要做的主要事情之一就是在编写代码时写注释,这会有所帮助。我认为贡献者将在领导者强调的部分上进行工作。在NoRM的情况下,这是测试,注释和惯用(到C#)代码。因此,我认为我们有一个非常专业,可维护的代码库。
Andrew Theken 2011年

我同意应在编写代码时写注释。(我也用自己的所有代码执行此操作,主要是因为我很自私,它有助于我在代码块之前编写叙述-它在我心中阐明了在实际执行操作之前我需要做的事情。)
quick_now 2011年

让我想起了我曾经碰到过的一句有趣的名言:“如果我很难写,那他们应该很难读。”
Denis de Bernardy 2011年

+ 1,@ quickly_now-您认为代码应该经过精心计划,经过良好测试并现在受到好评!您生活在什么样的疯狂星球上?


5

唐纳德·努斯(Donald Knuth)编写了两个程序,以帮助他比出版商更好地排版他的书中的数学公式。

这两个程序(最终版本)是使用Literate Programming编写的,它允许创建源代码的印刷排版版本,并将它们作为书籍出版。这些只是我读过的最好的文档记录的程序!

  • “计算机和排版,第B卷:TeX:程序”
  • “计算机与排版,第D卷:Metafont:程序”

它们不可用于在线阅读,但是Amazon也允许您通过以下网址 “查找” Metafont书:http: //www.amazon.com/Computers-Typesetting-D-Metafont-Program/dp/0201134381/

警告:这是沉重的负担,这就是为什么每本书要运行600页的原因。


1
注意:这是排版版本,无法在线使用。该源完全可用,并且可以(不费吹灰之力)用于生成打印版本。

4

美丽的代码》一书试图用几个样本来回答这个问题,这些样本的作者认为是开源项目中的美丽代码的示例。
替代文字


4
这本书值得一看吗?
奥利弗·韦勒

从任何意义上讲,这都不是“真实世界”的开源代码。这个答案是作弊!:P
Noldorin

1
我拥有它,没有被打动。大多数章节都很无聊,但是其中有一些亮点-如果我没记错的话,会解释map / reduce。
Martin Wickman

4

CodeIgniter

我从OS项目中看到的一些最干净,文档最完整的源代码。


1
PHP和最干净的?
Kugel

1
@Kugel:双方都同意。
乔什(Josh K)

只是看了一下CodeIgniter的源代码,它的确看起来非常结构化和简洁。我认为你可以在PHP中获得美丽。:)我一直喜欢源代码中的幽默:“ //还没有指定数据库?击败他们毫无意义... if(!isset($ params ['dbdriver'])...”
Bjarke Freund-Hansen

2
我在源代码偷看,我必须承认这是有据可查的,易于遵循的,我没有从OS PHP指望它。
OnesimusUnbound,2011年

2
另一个很棒的OS PHP框架是fuelphp(fuelphp.com),该文件也有文档记录,布局整洁,使用的命名约定不会使您费劲。那只是证明不是由PHP来指责意大利面条式的代码,通常是人们在编写代码。
Michael JV

3

我看过2个结构良好的项目:

  1. Django的
  2. 铬项目

特别是,第二件事基于几件事非常有趣:

  • 它如何将流程用于许多事物(选项卡,插件)以及如何组合在一起
  • 每个Windows,Mac,Linux均具有本机GUI的多平台
  • 网络套件集成

我也听说过Postgre的编写是干净的(与MySql相对),但是我自己还没有读过。


1
+1为PostgreSQL代码。这是非常干净和可读的。
丹尼斯·德伯纳迪

2

有人说Linux内核C代码相当不错。

(并不是我理解这件事!这可能是周围最好的书面开源C项目。)


1
对于优化的代码,它很棒。根据我的经验,可读性不是很好。当然,我还没有任何东西,只需阅读...
Michael K

1
是啊,没错。不幸的是,这个问题并未真正定义“最佳”,因此我采用了自己的定义。:)
Noldorin

2

我发现LLVM源代码非常易读。我很确定它是我所见过的最干净的C ++。如果您不熟悉它,那么它基本上就是一个编译器构建工具包。

  • 它具有广泛的测试套件。实际上,它至少有两套:一套用于测试功能,一套用于测试性能(LLVM本身及其生成的编译程序)。
  • 该代码是很好的注释。
  • 高度重复的代码(例如,各种后端中的指令匹配)是从更高级别的DSL(称为TableGen)描述中自动生成的。
    • 这也允许从同一描述中生成多个不连续的代码。例如,后端规范不仅用作编译器后端的一部分,而且还用于汇编程序和反汇编程序。
  • 它有很好的文档。

但是,这是一个很大的项目,所以不要指望能够快速准确地了解一切工作原理。但是,获得高层次的概述应该很容易。


1

这不是一个很大的项目,但是SubSonic ORM对我来说非常容易破解。这是我第一个真正能够真正修改所需方式的开源项目。其他大多数人最终都看了看源头,然后把头撞在墙上。我有几个小时的时间来部分支持PostgreSQL(基于SQL Server提供程序)。这是我见过的组织最完善的项目……尽管并不是说我看过很多开源项目。


0

首先是一个简单的示例:事件处理系统zope.event的代码。我使用了其他事件系统,这些系统将事件调度到不同的事件侦听器。当我看到zope.event代码时,是Facepalm的时候,我意识到一些事情可能会很简单。

它是用Python编写的,下面是全部代码:

subscribers = []

def notify(event):
    """ Notify all subscribers of ``event``.
    """
    for subscriber in subscribers:
        subscriber(event)

要添加订户,请执行以下操作:

from zope.event import subscribers
subscribers.add(MySubscriber())

我见过的最好的KISS例子。

再举一个更复杂的例子:火星人的代码库非常好,而且易于阅读,即使它使用了一些聪明的Python hacks。对于大多数使用火星人构建的Grok代码也是如此。


3
我不明白这段代码的优点。我不了解python,但是我只能在这里看到观察者模式的简单用法,除此之外没有其他。
barjak 2011年

您是否将其与其他事件系统进行了比较?为了简单起见,请举另一个Python示例:pypi.python.org/pypi/pyjon.events/1.1.1
Lennart Regebro 2011年

1
漂亮-我实际上在javascript中写了一些非常相似的东西。我想我很聪明?;)
Michael K

仅仅因为事件系统差强人意,并不意味着这就是出色的代码。我用大量的语言准确地看到了这段代码。更重要的是,我看到了类型安全的实现。
back2dos

@ back2dos:这是类型安全的。
Lennart Regebro

0

考虑阅读本书《开源应用程序的体系结构》。它应该使您对本书中讨论的项目为何以及如何做出设计决策提出批评。

与其寻找可能会长期困扰您的最佳项目,不如尝试和欣赏某些项目的设计,这也许超出了本书的范围。这可以帮助您在这些项目的成功基础上继续前进,而不必重复他们的错误(或者通常称为重新发明轮子)。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.