Open oliverklee opened 3 years ago
Somewhat alluded to in the above links is the idea of wrapping prose after every sentence, as this allows for cleaner commits when making minor alterations to it. This could equally be applied to markdown, HTML, and DocBlock and other comments. In fact this is what I have been doing with HTML. However, this comment is not actually rendered as intended because GFM in some instances (e.g. release notes on GitHub, and of course issue comments) will render line breaks literally.
The line length argument seems to be based on there being some upper limit to avoid extremely long lines (to avoid horizontal scrolling) and allow for easier review (i.e. with review comments per line), rather than what, specifically, it is exactly. The same applies to PHP (and other) code, where we enforce a limit of 120 characters (via PHPCS). Without a really compelling argument for a different line length for different file types, I would favour project-wide consistency, so that editors can be set up (with the help of .editorconfig
) with suitable window sizes etc. for the project.
The GFM issue may suggest not wrapping at all in markdown that is rendered by GitHub, but this only seems to be an issue with release notes, not with the README or viewing other .md
files within the source tree. Maybe there's a flag somewhere to control the behaviour.
There is also an 80 character line length argument for readability of prose in general (or perhaps about 66 characters). When editing, we still need to be able to read what we're editing as easily as possible. This would also be relevant to DocBlock and other comments in source code.
Related to #1038.
I've done some research concerning Markdown line lengths and XML indention.
Markdown line length limit:
XML indentation:
.editorconfig
settings)phive update
: 2 spaces (independent of.editorconfig
settings)So we should use 2 spaces indentation for XML, and use 80 characters line length for Markdown.