Здравствуйте, swame, Вы писали:

vsb>>Ещё хочу предложить мысль для обдумывания.

vsb>>В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.

S>Нет. одно и тоже можно написать длиной цепочкой, или несколькими последовательными операторами.
S>Это делает программист. Не форматтер.
S>Если что-то сдизайнено под длинную цепочку и потом автоматом форматируется, оно становится уже совсем нечитаемым.
S>И всякие мерджи гита на таком плохо будут работать.
S>Я при дежживаюсь второго стиля и на своем коде форматтером не пользуюсь, он не нужен просто .
S>Если только откуда-то достался какой-нибудь неряшливо отформатированный код и надо разобраться, тогда можно форматнуть.

Этот подход понятен, но повторюсь, в современных проектах всё чаще используется автоматическое форматирование. Это не я придумал, это можно считать уже общепринятым подходом. В том же go этот форматтер прям в поставку компилятора встроен. Если в таком проекте запушить самостоятельно отформатированный код, он просто не пройдёт валидацию и автора попросят настроить своё окружение, чтобы этого больше не повторялось.

vsb>>И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.

S>И как я узнаю при редактировании, мои изменения будут помечены как 1 измененная строчка, или весь метод окажется помеченным как измененный?

Опять же в современных стилях стараются избегать этого самого табличного форматирования, если я правильно понял, о чём речь. В том числе и потому, что изменение одной строки может потребовать изменение ещё и 100 строк вокруг, если нужно подправить вертикальное выравнивание. Это к слову.

Но вопрос мне не совсем понятен. На уровне файлов это тот же git, можно посмотреть `git diff --cached` или как там его, увидишь, что там будет помечено, как изменённое в git-е. На уровне IDE это уже как авторы IDE сделают. Сделают — и метод пометят, и statement, и что угодно.