Integration with common style guidelines

[djui]

@bbatsov has a nice written Clojure style guidelines repo and there is the default Clojure guidelines that cover many aspects that could be seen as generalized/community accepted, and being particularly seen as a company's flavour or "this is the only way to do it".

If that is reasonable and feasible, I think it is worth going through the guidelines, make them list items, and partition/rank them in relevance and implement new rules that do not exist yet in kibit.

The icing on the cake would be to somehow (maybe just links to the clj filename + lines) reference the guideline to the rule in the code.

I can help out if you see a point in doing this. Maybe 90% of the rules mentioned there are already covered (I have to look through the kibit source code again, you might have a better mental overview what's covered and what not, maybe for a good reason).

Edited to show list in first post

• [ ] Use seq as a terminating condition to test whether a sequence is empty (this technique is sometimes called nil punning).
• [ ] Prefer vec over into when you need to convert a sequence into a vector.
• [x] Use if-let instead of let + if - #54
• [x] Use when-let instead of let + when - #54
• [x] Use if-not instead of (if (not ...) ...)
• [x] Use when-not instead of (when (not ...) ...)
• [ ] Use when-not instead of (if-not ... (do ...).
• [x] Use not= instead of (not (= ...)). - kibit.rules.equality
• [ ] When doing comparisons, keep in mind that Clojure's functions <, >, etc. accept a variable number of arguments.
• [ ] Prefer % over %1 in function literals with only one parameter.
• [ ] Prefer %1 over % in function literals with more than one parameter.
• [ ] Don't wrap functions in anonymous functions when you don't need to.
• [ ] Don't use function literals if the function body will consist of more than one form.
• [ ] Favor the use of complement versus the use of an anonymous function.
• [ ] Leverage comp when it would yield simpler code.
• [ ] Leverage partial when it would yield simpler code.
• [ ] Prefer the use of the threading macros -> (thread-first) and ->> (thread-last) to heavy form nesting.
• [ ] Prefer .. to -> when chaining method calls in Java interop.
• [ ] Use :else as the catch-all test expression in cond
• [ ] Prefer condp instead of cond when the predicate & expression don't change.
• [ ] Prefer case instead of cond or condp when test expressions are compile-time constants.
• [ ] Use short forms in cond and related. If not possible give visual hints for the pairwise grouping with comments or empty lines.
• [ ] Use a set as a predicate when appropriate.
• [ ] Use (inc x) & (dec x) instead of (+ x 1) and (- x 1).
• [ ] Use (pos? x), (neg? x) & (zero? x) instead of (> x 0), (< x 0) & (= x 0).
• [ ] Use list* instead of a series of nested cons invocations.
• [ ] Use the sugared Java interop forms.
• [ ] Use the compact metadata notation for metadata that contains only slots whose keys are keywords and whose value is boolean true.
• [x] Denote private parts of your code. - not able to determine this statically
• [x] Be careful regarding what exactly do you attach metadata to. - eastwood maybe
• [x] Use _ for destructuring targets and formal arguments names whose value will be ignored by the code at hand. - eastwood
• [x] Follow clojure.core's example for idiomatic names like pred and coll. - not able to determine this statically
• [x] Prefer the use of keywords for hash keys. - stylistic, may be cases where string keys are required
• [ ] Prefer the use of the literal collection syntax where applicable. However, when defining sets, only use literal syntax when the values are compile-time constants.
• [ ] Avoid accessing collection members by index whenever possible.
• [ ] Prefer the use of keywords as functions for retrieving values from maps, where applicable.
• [ ] Leverage the fact that most collections are functions of their elements.
• [ ] Leverage the fact that keywords can be used as functions of a collection.
• [x] Avoid the use of ref-set whenever possible. - eastwood
• [x] Try to use swap! rather than reset!, where possible. - not possible to suggest an equivalent swap! form given a reset! form
• [ ] Prefer string manipulation functions from clojure.string over Java interop or rolling your own. - .toUpperCase, .toLowerCase, and .trim are candidates for this.
• [x] Reuse existing exception types. Idiomatic Clojure code — when it does throw an exception — throws an exception of a standard type - eastwood
• [ ] Favor with-open over finally

[bbatsov]

For what is worth - I'm planning to write a tool at some point, that automatically enforces the guidelines at some point(like I did for the Ruby style guide with RuboCop). When (if) this would happen, however, I cannot promise given my pretty busy schedule and the multitude of projects I'm involved with.

[danielcompton]

The Clojure guidelines have moved to http://dev.clojure.org/display/community/Library+Coding+Standards

[danielcompton]

I've looked at this and have a few thoughts. Because kibit reads source with a clojure reader, it isn't able to 'see' some of the infractions of the style guide as they aren't present in the read form. For example comments, whitespace and commas aren't available when the file has been read. Secondly, some of these style suggestions would be better addressed in eastwood which is a linter, whereas kibit's goal is suggesting more idiomatic ways of expressing a form. Thirdly, some of these suggestions aren't possible to check with Kibit because it reads without macroexpansion or evaluation. Lastly some people disagree with some of the style guide suggestions. Opening kibit up for extension by third party rules in #66 could let people check some of these rules without requiring them to be part of kibit.

All that being said, I think there's some good things in the style guide that might be able to go into Kibit. I'll check through Kibit to see which of these are already there or annotate this list with why I don't think they are appropriate.