On 21/09/2014 14:31, Lee Spector wrote:
I sort of agree with the bottom line here, but there are "non-throwaway" contexts in
which (2) won't apply because you are only "use"ing your own namespaces, and in which the
overall project is small enough that the chances of conflict in (1) are acceptably small and the
clutter of namespace annotations makes things less rather than more readable (contradicting (3)).
And the relative lack of ceremony of "use" is, IMHO, sometimes quite desirable.
I don't buy the argument that you can ever have code - of any complexity
- where the inclusion of explicit refers make it less readable. The
whole (ns) block is just boilerplate that you ignore until you need to
refer back to look something up, which is the only time it makes any
difference.
In general, making code arbitrarily shorter /might/ make it easier to
parse initially, but it doesn't automatically make it easier to
/understand/ (which is what "readability" in this context is all about).
If you want to understand some code, you also have to understand its
dependencies. That job is made harder if you can't tell, at a glance,
what the dependencies are.
However, I can see there might be cases where refer adds clutter and
maintenance work. For instance, if you have a main namespace that uses a
lot of sub-namespaces: in that case you might find yourself changing the
refers often, as your main functions change, but really everything is
just part of one logical package that happens to span several namespaces.
Legitimate occurrences of that pattern are pretty rare though; it tends
to be a result of over-architecting. Most of the time, if you see code
with (use) you should think carefully about whether it is really
helping, or if it's just masking a problem. For example, if you have
excessive coupling between namespaces like this then you probably ought
to refactor. It's a /code smell/.
- Robert
--
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.
