Haskell模块命名约定

我应该如何为程序命名我的Haskell模块而不是库和将它们组织在一个层次结构中？Haskell模块命名约定

我正在制作一个名为Luminosity的光线追踪器。首先，我有这些模块：

Vector Colour Intersect Trace Render Parse Export

每个模块都很好，但我觉得这是缺乏组织。

首先，我把每个模块放在Luminosity之下，所以例如Vector现在是Luminosity.Vector（我认为这是haskell程序的标准？）。

然后我想：Vector和Color是独立的，可以重用，所以它们应该分开。但是它们太小而无法变成图书馆。

他们应该到哪里呢？已经（在hackage上）Data.Vector和Data.Colour，所以我应该把它们放在那里？或者这会引起混淆（即使我将它们与其他本地进口分组在一起）？如果不在那里，应该是Luminosity.Data.Vector还是Data.Luminosity.Vector？我很确定我已经看到了两个使用过，虽然也许我碰巧看到一个使用非传统结构的项目。

我也有一个简单的TGA图像输出器（Export），它可以独立于Luminosity。看起来正确的位置是Codec.Image.TGA，但是再次，Luminosity应该在那里，如果是的话，在哪里？

这将是很好，如果Structure of a Haskell project或其他维基解释这一点。

来源

2012-07-21 mk12

如果您想制作可重复使用的代码，请将其打包到库中。大小并不重要。 – 2012-07-21 19:06:24

Vis可重用模块用于几何图元 - 代数类型，矢量和颜色非常容易定义，因此对于认真使用Haskeller而言，希望自己定义它们而不是依赖另一个库。然后他们控制他们的表示，不必担心依赖性问题（API变更，作者将要失踪等） – 2012-07-22 06:11:33

首先，我把每一个模块Luminosity

下，我认为这是一个很好的举措。它向所有正在阅读代码的人澄清，这些模块专门用于Luminosity项目。

如果您编写的模块的目的是模拟或改进现有库，或者填写缺少某个特定通用库的缺口，那么在该罕见情况下，请删除前缀并将其命名为一般。举一个例子，看看pipes软件包出口Control.Monad.Trans.Free的方式，因为作者出于某种原因不满意Free monads的现有实现。

然后我想，Vector和Color几乎是独立的，可以重用，所以它们应该分开。但他们正在向小型图书馆分类（分别为125和42行）。他们应该去哪里？

如果您不制作单独的库，那么可能会将它们留在Luminosity.Vector和Luminosity.Colour。如果您确实创建了独立的库，那么请尝试通过电子邮件发送这些库的目标受众，并了解其他人如何认为这些库应该被命名和分类。不管你是否将它们分成单独的库，完全取决于你自己，以及你认为这些单独的库可能为其他人提供多少好处。

来源

2012-07-22 03:02:19

我接受了你的答案，因为我认为这对你最有帮助，对我来说也是特定的，但我把你的，诺曼和斯蒂芬的（对这个问题的评论）建议结合起来。我会把所有东西都放在Luminosity下。“就像你说的。正如斯蒂芬所说，我不会为从小模块中删除图书馆或删除前缀而烦恼，无论如何，每个程序都可能需要自己的矢量和颜色。我会保持一切平坦，而不是因为诺曼给出的原因在“光度”下引入层次结构。 – mk12 2012-07-24 21:17:22

除非你的程序是真的大，不要组织层次结构中的模块。为什么不呢？因为虽然计算机擅长层次结构，但人们不是。人们擅长有意义的名字。如果你选择好名字，你可以在一个平面名称空间轻松处理150个模块。

我觉得[平面名称空间]缺乏组织。

分层组织本身并不是目的。为了将模块拆分成层次结构，您需要原因。好的理由往往与信息隐藏或重用有关。当你引入信息隐藏的时候，你已经到了图书馆设计的中途，当你谈论重复使用时，你正在有效地建立一个图书馆。将一个大型程序变成“小程序加图书馆”对于软件evolution来说是一个很好的策略，但它看起来像刚刚开始，而且你的程序还不够大，无法以这种方式发展。

这些问题在很大程度上与您正在使用的编程语言无关。我建议读一些David Parnas关于产品线和计划家庭的工作，以及Matthias Blume的低估论文Hierarchical Modularity。这些作品将为您提供关于何时开始实现层次结构的更具体的想法。所有的

来源

2012-07-21 20:35:58

这是一个有趣的观点！我的程序中通常至少有*一些*等级组织。 “真的很大”的量级门槛是多少？ – 2012-07-21 21:37:36

我有点理解你的观点，但我不同意这种独立于编程语言的观点。至少为了避免命名冲突，应该引入一个级别（'Luminosity。*'） - 我不确定你是否将它作为一个层次来计算。我没有真正询问层次结构的利弊，而是在具体询问哈斯克尔的约定。也许这是自相矛盾的，但Haskell的'base'层次结构（以及Hackage上的软件包）看起来与Java或Python的惯例有很大的不同，也不那么简单。 – mk12 2012-07-22 02:55:06

至于平面和层次的讨论，我为我的8模块程序制作层次结构的原因是：大约一半的模块与光线追踪无关。我可以在本地文件浏览器中适当地组织它们，但在GitHub上它们都是按字母顺序排列的。我认为这会让人们更轻松地通过分组相关模块来完成。这似乎与你所争论的完全相反。 – mk12 2012-07-22 03:28:58

Haskell模块命名约定

回答

相关问题