There are quite a few, genuine useful cases where one wants to overflow the recommended 75 (some use 72) character rule.
Breaking long lines or manually breaking long compiler or other tool-generated outputs is just confusing and error-prone.
This does not mean that we should stop wrapping manually written text at a sane length, but enforcing the rule with a script seems to yield questionable results while creating quite a bit of friction.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.
There are quite a few, genuine useful cases where one wants to overflow the recommended 75 (some use 72) character rule.
Breaking long lines or manually breaking long compiler or other tool-generated outputs is just confusing and error-prone.
This does not mean that we should stop wrapping manually written text at a sane length, but enforcing the rule with a script seems to yield questionable results while creating quite a bit of friction.
Requirements
Before submitting your PR, please make sure you addressed the following requirements:
git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.unsafecode is properly documented.