> On Jul 3, 2011, at 3:13 AM, Sean Corfield wrote: >> Since I mostly work with 50-100kloc projects, I think 5-10kloc >> projects are kinda small :) > > > My point was that I'm running into interesting questions even with a small > program. The answers are not obvious to me. There's evidence I'm not alone, > so those to whom the answers *are* obvious would help the community by > describing them. > > * An example: organizing code into namespaces (skippable) > > I was uncertain that Midje's "sweet" (syntactically sugared) interface would > catch on, so I organized it by translation layers. I wrote the "unprocessed" > layer first; it had functions that worked solely on maps. The "semi-sweet" > layer provided macros that introduced some useful conventions but had only > one syntactic innovation. It was easy to translate the `expect` and `fake` > macros into "unprocessed" function calls on maps. Then I added the "sweet" > layer that has a considerably more ambitious set of macros that translate > `facts` into `expects` and `fakes`. > > As time went on, I pulled out utility functions into namespaces like > [midje.util thread-safe-var-nesting laziness file-position]. But that > organization failed. When I divide things up into files, I want the division > such that I usually find things in the first place I look. That wasn't > happening. > > So I started migrating to an organization based on verbs (this is a > functional language, right?). So I have namespaces like [midje.midje-forms > recognizing translating building]. Two problems: 1) New features require > recognizing, translating, and building, so all the hopping around files was > annoying. 2) The functions didn't fall into such clear-cut categories that I > could reliably find things in the first place I look. (Unsurprising, since > clear-cut categories are rare in nature: > http://www.exampler.com/testing-com/writings/pnsqc-2005-communication.pdf) > > Now I'm moving toward an organization around nouns, which feels a bit too OO > to me, but at least I'm far enough in the project that the key concepts/nouns > are likely to stay stable. > > This progression feels a lot more wasteful than it would have been in Java > (which has IDE support) or Ruby (which lets you mention a file once and have > it be available throughout the program). So I'd have preferred to get it > (more) right in the first place. > > * What would help > > It'd be useful for people happy with their multi-namespace codebases to > volunteer them as exemplars. What's grouped together and why? What are the > dependencies? How'd you arrive at this structure? A really interesting thing > to do would be to implement a feature and narrate how you decide where to put > things, where existing things must be, and so forth. [I spend a fair amount > of time parachuting into projects and learning the code structure by pairing. > Works pretty nicely.]
On large projects I do the following: (1) Use "require :as prefix" everywhere. This felt ugly at first, but puts pressure on naming in way that is beneficial as the codebase grows. (2) Think of the consumer of the lib, not the author. As a user of Midje, I would want all the utility fns in a single namespace (if they were separated from the domain API at all). In general, I have found that namespaces should be larger than my OO intuition would have them be. Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
