I recently browsed parts of that guide and was surprised how many bits I
disagreed with. Especially around the "one space in these rare cases" bits.
Not that that is a bad thing it's just my personal opinion that everything
should always use two space indentation.

And on a client project recently, it was decided (when I wasn't around)
that the arguments to a function should always be on a newline:

(defn foo
  [x]
  (+ x x))

Instead of:

(defn foo [x]
  (+ x x))

I disagree with this idea also, but whatever, it's just style. It's not
like I suddenly can't read Clojure code since it's in the wrong style.

With so many different views, I think it's unwise to lock any editor into
any style. Instead give users options, and update the Clojure Style Guide
with the following (paraphrased) quote from Pirates of the Caribbean: "this
Code of Styling is more what you'd call "guidelines" than actual rules."

Timothy

On Sat, Dec 20, 2014 at 6:11 AM, Fluid Dynamics <a2093...@trbvm.com> wrote:

> A way to hint indentation to the tooling would be nice.
>
> Perhaps a metadata on vars such as {:body-indent #{then-clause
> else-clause}} that could tell tools to indent an "if" this way:
>
> (if condition
>   then-clause
>   else-clause)
>
> instead of this way:
>
> (if condition
>     then-clause
>     else-clause)
>
> rather than the current ad-hoc special-casing that seems to be used at
> present. (Ad hoc special-casing would still be needed for special forms,
> including "if", but this could be used with macros and perhaps with
> functions if someone wanted that.)
>
> (Formal specification for that suggestion: the metadata key :body-indent
> should have a value that is a set of symbols, which are some subset of the
> symbols appearing in arglists of the bound macro/function. Editors and
> pretty-printers and other tools would take this as a hint to indent the
> corresponding parameters only two spaces, if on lines of their own, rather
> than to align with parameters inline with the operator on the form's first
> line.)
>
>  --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to