Are there any Clojure Principles?

Question

1. Are there any Principles for Clojure ?

   a. Like the S.O.L.I.D. Object-Oriented Design Principles for OO languages like Java ?

   b. or others more heuristic, like "Tell don't ask", "Favor Composition vs Inheritance", "Talk to Interfaces" ?

2. Are there any design patterns (for flexible code) ?

3. What is the counter part of the basic of functional-programming like encapsulation for object-oriented ?

Know of any resources for these ?

Answer 1

To your first question: no. ^†

Clojure is here to help you get things done correctly, quickly, and enjoyably. Everything after that is gravy.

And there's a lot of gravy. I don't presume to know the Clojure way, even if there is one, but here are some guidelines I've been told and have discovered while writing in Clojure:

1. First, get something working. Then you can examine, test, and optimize if necessary. There's a reason that the time macro is in the core language. Correctness before quickness, to be cute.

2. Abstract. If you are repeating yourself, you're probably not doing it right. Compose, curry and combine functions.

3. Separate side-effects from your logic. e.g. if you want to format and save a string, format it in one function, then use another function to save it, however you need to.

3a. Don't go too crazy with this. Sometimes it's better to have a a few anonymous functions than a bunch of one-line defns littering your code.

5. Test. Rich gave you a REPL for a reason; use the hell out of that REPL.

6. Don't clutter your namespace. We're clean in Clojure-land. Qualify your uses or use :only what you need. Make your code readable.

7. Know the core library. Not just clojure.core, but clojure.java.io, clojure.string, clojure.set and everything in between. If you think Clojure should have a function to do X, it probably does. You can use apropos (from, yes, another core library: clojure.repl).

8. Document your code. Docstrings are a beautiful thing. If you have a tendency to be verbose, the doctsring is the place to let loose. But, know too that good code often "documents itself". If the code is self-explanatory, there's no need to be pedantic.

9. This is a functional language. When you can, use a function. Protocols, macros and records are all great: but when you can get away with it, use a function. You can compose, combine, map, reduce, iterate (the list goes on, and on, and on…) functions. That's really nice.

10. Above all, break the above rules if it makes sense. But be prepared to rethink and refactor. If you've kept your code modular enough, refactoring your code should be a matter of reorganization and recombination.

Some other tips: read other people's code. If you begin to read code, and become good at reading code, you'll become better at writing your own, and you're likely to learn new things, too: there's more than one way to do just about everything.

Finally, read though the Clojure Library Coding Standards to get an idea of what's expected in production Clojure code.

† At least, not yet.

Answer 2

Hard question.

Clojure is very flexible. So they are best practices, but they aren't nearly as important as for java.

I write here a few examples of advices from the most general to the most particular families.

There are advices for programming in general: write a lot of tests, write something correct and nice, profile and optimize when needed

There are advices for functional programming: write small functions, write pure functions, compose the small functions, factor your code through functions, try to use combinators when possible...

There are advices for LISP: use macro to factor out repetitive patterns, build your program bottom-up. (See Paul Graham's 'on LISP' for a better explanation than mine)

There are also some advices specifically for Clojure: follow the careful analysis of state and identity ( http://clojure.org/state , for a very good explanation), try to use seqs and their functions when possible, write doc strings for functions

A good source for more advices are the Clojure Library Coding Standard http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards

But all these advices are just advices, and Clojure can be used by someone that do not want to follow these advices, because, as a Lisp, it is very flexible.

As far as design pattern are concerned, functional programmer rarely think in these terms, as most of them has been designed for OO languages and do not apply in a functional language.

Peter Norvig has interesting slides on Design Pattern and LISP/Dylan: http://norvig.com/design-patterns/

Hope that helps.