Page MenuHomeFreeBSD

style: Relax 80 column rule
ClosedPublic

Authored by imp on May 13 2021, 10:01 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 19, 1:12 AM
Unknown Object (File)
Mon, Apr 8, 4:01 PM
Unknown Object (File)
Feb 22 2024, 8:04 AM
Unknown Object (File)
Jan 17 2024, 6:25 PM
Unknown Object (File)
Dec 22 2023, 11:27 PM
Unknown Object (File)
Dec 21 2023, 10:53 PM
Unknown Object (File)
Dec 20 2023, 4:45 AM
Unknown Object (File)
Dec 10 2023, 12:35 PM

Details

Summary

Note that the 80 column rule has been relaxed for some time when
things are clearer when a little longer. Add in that things that people
grep for, such as error messages, shouldn't be broken up which is
the most common reason people exceed 80 columns intentionally.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

imp requested review of this revision.May 13 2021, 10:01 PM

I still use an 80 character limit, and an 80 character-wide Terminal window.

Usually my opinion means everyone else has moved on :).

In D30255#679519, @sef wrote:

I still use an 80 character limit, and an 80 character-wide Terminal window.

Usually my opinion means everyone else has moved on :).

+1, and I use it quite often.

Shorter lines means more tmux panes/vim vertical splits...

This revision is now accepted and ready to land.May 14 2021, 10:24 AM
imp retitled this revision from style: allow 120 to style: Relax 80 column rule.May 27 2021, 2:11 PM
imp edited the summary of this revision. (Show Details)

Update to reflect discussion here and on IRC. Rather than
take a bold step to 120, just relax 80.

This revision now requires review to proceed.May 27 2021, 2:12 PM
jhb added a subscriber: jhb.

This is better, thanks.

This revision is now accepted and ready to land.May 27 2021, 3:33 PM

If we were to update clang-format to reflect the new rules, what value would we write there?
Personally I’d love to see something explicit so we leave all of the style(9) discussions to the standard formatter.

If we were to update clang-format to reflect the new rules, what value would we write there?
Personally I’d love to see something explicit so we leave all of the style(9) discussions to the standard formatter.

Keep it at 80 if you want clang-format to produce something that's acceptable. Also, clang-format doesn't have a 'don't break up long strings' rule that can be enabled last time I checked.

However, style(9) documents the range of acceptable and preferred styles in the tree. There isn't a canonical representation of style(9) for some code, as there's good reasons to vary a bit from any normal forms to improve the readability of the code. This is unlikely to change as there's too much code in the tree to reformat to 'one canonical style': the churn would cause more problems than it would solve.

This revision was automatically updated to reflect the committed changes.