* Don’t use “use” - agree completely. * Use consistent, unique namespace aliases - agree. This helps tremendously when consistent across projects given the var

* Don’t use “use” - agree completely. * 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.