I guess that would depend on the density of the language - I prefer 2 for clojure / common lisp and 4 for C and python.

At the end, we're trying to optimize for readability, and the horizontal indentation needs to be more or less in harmony with how tight the code is vertically... for example, see this completely random and subjective selection from two of my projects:

    void consumeInput(gap * sudoku, inputQueue * q){
        unsigned short int x, y, i, data;
        input * ptr = q->head;
        q->head = ptr->next;
        x = ptr->x;
        y = ptr->y;
        data = ptr->data;
        free(ptr);
        if(!q->head)
            q->tail=NULL;

        if(DEBUG)
            fprintf(stdout, "%d %d %d:\n", x, y, data);
        x--;y--;



    (defn username-from-req [ring-request]
      (when-let [identity (:cemerick.friend/identity (:session ring-request))]
        (let [[[:authentications auths]
               [:current curr]] (vec identity)]
          (when (and auths curr)
            (str (:identity (auths curr)))))))

(My) C functions tend to be longer but with shorter lines, whereas with clojure, I end up writing denser functions with fewer lines with more meat, both in term of characters and semantics. Thus (again, for me), clojure looks better if lines are more "tight", and C needs more breathing space.

Off topic, but could you explain the destructuring form you've used in your Clojure function? I've not seen destructuring with keywords in first position (in vectors, no less) before: is this something new for 1.9? I can't get it to work under 1.8.

What does it offer over the standard associative destructuring form:

    (let [{auths :authentications, curr :current} identity]
      ...

Well it seems to work with 1.7. Try:

    (let [[[:a a]
           [:b b]] (vec {:a 1
                         :b 2})]
      (println a b))

But yeah, it's just an old and ugly hack from when I knew no better. It should look like your version.

You're right, it works under 1.7. But not under 1.8: I get an "Unsupported binding form" exception.

A bit of digging suggests it was an unwanted side effect of allowing destructuring of name-spaced keywords in maps, introduced in 1.5:

> CLJ-1318 ("Support destructuring maps with namespaced keywords") introduced two potentially undesired behaviours:

> [snip]

> 2. Keywords were allowed in any binding key positions. Keywords are converted to symbols (retaining namespace) and treated according to the rules of symbols in the rest of the destructuring logic. From what I understand the idea was to allow keywords only in map destructuring, but again the change change was effected for any binding key.

-- http://dev.clojure.org/jira/browse/CLJ-1778

1.8 removed keyword-first destructuring forms for vectors.

We had people in the same team with the same differing opinions 15 years - we compromised on a coding standard of 3 spaces, and anything else looks wrong to me now.