Re: [PATCH] docs: correct trailer `key_value_separator` description

[Junio C Hamano <gitster@pobox.com>]

"Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:

> My interpretation of this is
>
> 1. Commit messages are flowed/reflowed to 72 columns
> 2. Code is reflowed to 80 columns (enforced by tools like clang-format)
>    • See `.clang-format` and `.editorconfig` (kept in synch.)
> 3. Source documentation (AsciiDoc) is reflowed to 72 opportunistically;
>    not every time (in order to avoid diff noise) but when it feels like it
>    makes sense
>
> Maybe SubmittingPatches should mention that last point? If my
> interpretation is correct.

I do not know about #2.  I've seen cases where a patch trying to
stick to the hard 80-column limit is hurting readability a lot.  I
think the moral of the story is that code should never be reflowed
mechanically without thinking---rather developers, when they see the
need to go way too deep in indentation levels, should learn to take
it a sign that they need to first refactor their code, e.g. with
smaller helper functions with meaningful names.