oakmac / oakmac/standard-clojure-style-js
Rationale for not enforcing line length
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 137
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
Hey! I finally took a few minutes to try this out on our codebase at work where we currently use zprint. I like the idea of not needing to maintain a config file and potentially having a good vim plugin. However there are at least two areas important to us in which standard clojure style (SCS?) is less aggressive than zprint: line length enforcement and map value alignment.
I see this is an explicit design choice; from the readme:
no enforced max line length
text editors have the ability to wrap lines if you desire
However text editor line-wrapping is much less readable than having the formatter break lines + apply proper indentation. e.g. consider the following snippet wrapped at 50 characters (only for demonstration, obviously you'd have a longer length in a real project):
;; unformatted / unwrapped
(defn my-function [...]
(let [...]
(another-function argument-one argument-two argument-three)))
;; wrapped by vim in a window width of 50 characters and with `set lbr`
(defn my-function [...]
(let [...]
(another-function argument-one argument-
two argument-three)))
;; formatted
(defn my-function [...]
(let [...]
(another-function argument-one
argument-two
argument-three)))
When you've got a large function with many lines that have to be wrapped, things get really messy. It's probably the biggest benefit I get from zprint.
If you're already set on not enforcing line length, an expanded rationale could be nice. e.g. is your recommendation that I should just deal with the text editor line wrapping? Or enforce line lengths manually in PR review (I think that would contradict the purpose of this project though)? Use a linter to enforce line length, and then the PR author can break the lines manually without the need for PR feedback saying to do so?
If you'd recommend the linter route, it'd be great to have some rationale for why that approach is recommended over just having the formatter break the lines for you. e.g. do you think doing line breaks manually is better anyway, or is it just that the cost (making SCS implementation more complicated) outweighs the benefits?
This discussion on how gofmt doesn't enforce line length was interesting. However one of the points that seems relevant is that apparently in Go lines tend to not get very long in the first place? In any case, before introducing zprint it is was certainly a pain point for me.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the README section stating “no enforced max line length,” then review the examples and linked discussion in this issue. Clarify whether users should rely on editor wrapping, manual breaks, or a linter, and document the rationale for that choice. Done means the README explains the trade-offs and recommended workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clojure, javascript
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100