* Use consistent, unique namespace aliases - agree. This helps tremendously when consistent across projects given the varying tooling capabilities. We even have a dictionary of namespace -> alias mappings that is expanded as new commonly used namespaces appear.
* Use long namespace aliases - agree partially. I have a few favourite namespaces present in pretty much every project that get a single letter alias.
* Choose readability over compactness - agree partially. Another part of the solution is keeping the functions small and all the types explicit. However, there's a fine line between that and having to use something like a hungarian notation for the local variables.
* Don’t rely on implicit nil-to-false coercion - agree. However, I never find myself in this situation. Mostly because I just don't use plain booleans. Pretty much always you can use an enum (keyword) instead to better express the intent. When used locally - in the scope of a single function - I find that boolean-nil problem doesn't cause any issues.
* Avoid higher-order functions - agree completely. `comp` and `partial` in Clojure are awkward. If you find yourself using them, you're probably nesting too many lambdas with hash (#) notation - move some of them out into a `let`.
* Don’t spare names - agree partially. The suggestion is definitely more readable. I just love writing threading expressions.
* Don’t use first/second/nth to unpack tuples - agree completely.
* Don’t fall for expanded opts - agree completely.
* Use * as prefix for references - agree. This needs some sort of a blessed reference in the Clojure documentation. Something to syntactically mark constants, e.g. `+constant+`, something to mark refs, e.g. `+ref`.
* Align let bindings in two columns - this is purely a matter of preference. I don't care either way.
* Use two empty lines between top-level forms - also a matter of preference. I prefer a single line.