用於構建Clojure源代碼的習慣性方法

Question

我對人們如何構建Clojure源代碼感興趣。

被使用到Java，我很熟悉，每個源代碼文件一類的模式，捆綁適當的註釋和批註等

的所有數據和方法定義然而Clojure中提供了更大的靈活性

：，我不知道我應該怎麼構建我的項目（有可能最終成爲一箇中等規模的應用程序，也許5000線，三個或四個不同的子系統）

特別是我與摔跤

• 我應該使用什麼指導方針確定代碼是否應該位於單個命名空間中，而不是分離到不同的命名空間中？
• 每個協議/數據類型是否都有自己的命名空間+源文件及其關聯的函數集？
• 我應該什麼時候需要使用其他名稱空間？

Answer 1

我來自Java背景以及相當多的Ruby和一些Go。下面是我做的那一刻是什麼，一個月左右到的Clojure：

• 我想一個命名空間作爲一個語義單位，而且還是一種共同爲特定目的，如數據類型和操作碼在上面。

我有兩個慣例命名空間VS文件：

• 爲了使之與一個文件短小單位（我用〜1000線爲其中一個文件應該被分割的限制）我有每個文件一個名稱空間，目錄路徑加文件名與命名空間相同。這在Java中是一件好事，我認爲，它使得從文件中找到命名空間或反之亦然輕而易舉。
• 對於需要多個文件的較大單元，我使用Go約定：命名空間與目錄路徑匹配，目錄中的所有文件共享相同的命名空間。在這些情況下，我通常會分配一個帶有固定名稱（'main'）的主文件，用於加載其他文件並與其進行交互。

作爲一個命名空間示例，我有一個解析器讀取格式並將其轉換爲HTML。對於解析器（語義單元），我有一個單獨的命名空間，並且在子目錄中分割了幾個文件：Lexer，解析器，HTML轉換和一個包含使用解析器的主要公共API的主文件。

我不會爲每個數據類型自動使用一個名稱空間，它取決於數據類型的範圍。如果它是一個很大的，也許。但是對於像Point這樣的數據類型，有兩個字段和幾個函數，我寧願把它包含到一個更通用的命名空間中，比如Geometry。

需要與用途：

• 具有適當短的別名要求幾乎無處不在。
• 這也允許重用核心名稱：我的特殊用途樹數據類型具有「get」操作以適合地圖;使用require不會產生衝突：「get」是Clojure核心get，「tree/get」是我的數據類型。
• 我使用「use」僅用於我認爲是「核心擴展」的內容，就像我製作屬於自己的「map-if」，它是map和filter合併爲一個。