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模塊命名約定

回答

相關問題