Closed thomaseizinger closed 3 years ago
Off the top of my head, given that it increases the barrier (for newcomers) to contribute, I would deem it not worth the effort. That said, this is not a strong opinion.
As a middle-ground, I would very much appreciate if all specs would be wrapped at 80 (or X) characters, though not sure whether others see that as worth a debate by itself.
Okay, I'll see to just automate it on my end then :)
To be perfectly honest, personally I've found it to be a bigger barrier to follow guidelines I have to guess (text wrapping at X characters) because there is no tooling to help / enforce it.
Might just be my OCD kicking in though :P
I've noticed that most (all?) spec documents are formatted with hard line breaks based on line width.
I would like to suggest an alternative way of formatting specs, in particular using semantic line breaks.
The main advantage I would point out is that natural language tends to be changed on a per-sentence basis, i.e. add a complete sentence, rewrite an existing one, split one into two, merge two into one, etc.
Git on the other hand works on a line-by-line basis. If newlines occur only after each sentence or at meaningful places within a sentence, what shows up in the diff is much closer to the semantic changes that were made.
Note that semantic line breaks are allowed mid-sentence. Consequently, readability of the specs in plain-text shouldn't suffer too much from such a change, esp. if we strive for short sentences at the same time.
If people want to stick to the current formatting that is also fine by me but then I would suggest a script or tool to be added to the repository that produces the desired formatting. Manually formatting things is tedious.