Сообщение Re[4]: Ширина кода - газетная vs книжная от 12.01.2025 17:19
Изменено 12.01.2025 17:22 swame
Re[4]: Ширина кода - газетная vs книжная
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, swame, Вы писали:
vsb>>>Ещё хочу предложить мысль для обдумывания.
vsb>>>В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
S>>Нет. одно и тоже можно написать длиной цепочкой, или несколькими последовательными операторами.
S>>Это делает программист. Не форматтер.
S>>Если что-то сдизайнено под длинную цепочку и потом автоматом форматируется, оно становится уже совсем нечитаемым.
S>>И всякие мерджи гита на таком плохо будут работать.
S>>Я при дежживаюсь второго стиля и на своем коде форматтером не пользуюсь, он не нужен просто .
S>>Если только откуда-то достался какой-нибудь неряшливо отформатированный код и надо разобраться, тогда можно форматнуть.
vsb>Этот подход понятен, но повторюсь, в современных проектах всё чаще используется автоматическое форматирование. Это не я придумал, это можно считать уже общепринятым подходом. В том же go этот форматтер прям в поставку компилятора встроен. Если в таком проекте запушить самостоятельно отформатированный код, он просто не пройдёт валидацию и автора попросят настроить своё окружение, чтобы этого больше не повторялось.
Еще раз. То что я не юзаю автоформатирование это частный вопрос. А то что программит может написать длинный неоправданно замудренный оператор на несколько строк никакой форматтер не исправит.
Можно написать так.
И автоформаттер сделает так
И не узнаешь на каком условии вышли из цикла.
А можно написать так
Разница понятна?
В моем стеке к счастью автоформатирование сделано отдельно по запросу. И настраивается.
vsb>>>И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
S>>И как я узнаю при редактировании, мои изменения будут помечены как 1 измененная строчка, или весь метод окажется помеченным как измененный?
vsb>Опять же в современных стилях стараются избегать этого самого табличного форматирования, если я правильно понял, о чём речь. В том числе и потому, что изменение одной строки может потребовать изменение ещё и 100 строк вокруг, если нужно подправить вертикальное выравнивание. Это к слову.
Если не упарываться, чтобы все было ровно всегда одинаково и для особо длинных строчек сделать исключение, то нет такой проблемы и все красиво.
vsb>Но вопрос мне не совсем понятен. На уровне файлов это тот же git, можно посмотреть `git diff --cached` или как там его, увидишь, что там будет помечено, как изменённое в git-е. На уровне IDE это уже как авторы IDE сделают. Сделают — и метод пометят, и statement, и что угодно.
Например, я вставляю условие в начало большого метода и выход из условия в конце.
При автоформатировании, естественной во все вложенные строчки естественно, вставятся пробелы. Все будут изменены.
И нужно проследить несколько таких изменений, естественно будет каша. А такие изменения бывают ч
Если я забью в это в случае на форматирование, которой тут может быть и не показатльны, покажет четко изменение 2 строчек.
vsb>Здравствуйте, swame, Вы писали:
vsb>>>Ещё хочу предложить мысль для обдумывания.
vsb>>>В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
S>>Нет. одно и тоже можно написать длиной цепочкой, или несколькими последовательными операторами.
S>>Это делает программист. Не форматтер.
S>>Если что-то сдизайнено под длинную цепочку и потом автоматом форматируется, оно становится уже совсем нечитаемым.
S>>И всякие мерджи гита на таком плохо будут работать.
S>>Я при дежживаюсь второго стиля и на своем коде форматтером не пользуюсь, он не нужен просто .
S>>Если только откуда-то достался какой-нибудь неряшливо отформатированный код и надо разобраться, тогда можно форматнуть.
vsb>Этот подход понятен, но повторюсь, в современных проектах всё чаще используется автоматическое форматирование. Это не я придумал, это можно считать уже общепринятым подходом. В том же go этот форматтер прям в поставку компилятора встроен. Если в таком проекте запушить самостоятельно отформатированный код, он просто не пройдёт валидацию и автора попросят настроить своё окружение, чтобы этого больше не повторялось.
Еще раз. То что я не юзаю автоформатирование это частный вопрос. А то что программит может написать длинный неоправданно замудренный оператор на несколько строк никакой форматтер не исправит.
Можно написать так.
if (terminal.id < 0) or ((params.IslandIndex >= 0) and (terminalInfo.Island <> params.IslandIndex)) or
(if island.TmStUpdate < params.StartTime) then continue;И автоформаттер сделает так
if (terminal.id < 0) or ((params.IslandIndex >= 0) and (terminalInfo.Island <>
params.IslandIndex)) or (if island.TmStUpdate < params.StartTime) then
continue;И не узнаешь на каком условии вышли из цикла.
А можно написать так
if terminal.id < 0 then
continue;
if params.IslandIndex >= 0 then
if terminalInfo.Island <> params.IslandIndex then
continue;
if island.TmStUpdate < params.StartTime then
continue;Разница понятна?
В моем стеке к счастью автоформатирование сделано отдельно по запросу. И настраивается.
vsb>>>И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
S>>И как я узнаю при редактировании, мои изменения будут помечены как 1 измененная строчка, или весь метод окажется помеченным как измененный?
vsb>Опять же в современных стилях стараются избегать этого самого табличного форматирования, если я правильно понял, о чём речь. В том числе и потому, что изменение одной строки может потребовать изменение ещё и 100 строк вокруг, если нужно подправить вертикальное выравнивание. Это к слову.
Если не упарываться, чтобы все было ровно всегда одинаково и для особо длинных строчек сделать исключение, то нет такой проблемы и все красиво.
vsb>Но вопрос мне не совсем понятен. На уровне файлов это тот же git, можно посмотреть `git diff --cached` или как там его, увидишь, что там будет помечено, как изменённое в git-е. На уровне IDE это уже как авторы IDE сделают. Сделают — и метод пометят, и statement, и что угодно.
Например, я вставляю условие в начало большого метода и выход из условия в конце.
При автоформатировании, естественной во все вложенные строчки естественно, вставятся пробелы. Все будут изменены.
И нужно проследить несколько таких изменений, естественно будет каша. А такие изменения бывают ч
Если я забью в это в случае на форматирование, которой тут может быть и не показатльны, покажет четко изменение 2 строчек.
Re[4]: Ширина кода - газетная vs книжная
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, swame, Вы писали:
vsb>>>Ещё хочу предложить мысль для обдумывания.
vsb>>>В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
S>>Нет. одно и тоже можно написать длиной цепочкой, или несколькими последовательными операторами.
S>>Это делает программист. Не форматтер.
S>>Если что-то сдизайнено под длинную цепочку и потом автоматом форматируется, оно становится уже совсем нечитаемым.
S>>И всякие мерджи гита на таком плохо будут работать.
S>>Я при дежживаюсь второго стиля и на своем коде форматтером не пользуюсь, он не нужен просто .
S>>Если только откуда-то достался какой-нибудь неряшливо отформатированный код и надо разобраться, тогда можно форматнуть.
vsb>Этот подход понятен, но повторюсь, в современных проектах всё чаще используется автоматическое форматирование. Это не я придумал, это можно считать уже общепринятым подходом. В том же go этот форматтер прям в поставку компилятора встроен. Если в таком проекте запушить самостоятельно отформатированный код, он просто не пройдёт валидацию и автора попросят настроить своё окружение, чтобы этого больше не повторялось.
Еще раз. То что я не юзаю автоформатирование это частный вопрос. А то что программит может написать длинный неоправданно замудренный оператор на несколько строк никакой форматтер не исправит.
Можно написать так.
И автоформаттер сделает так
И не узнаешь на каком условии вышли из цикла.
А можно написать так
Разница понятна?
В моем стеке к счастью автоформатирование сделано отдельно по запросу. И настраивается.
vsb>>>И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
S>>И как я узнаю при редактировании, мои изменения будут помечены как 1 измененная строчка, или весь метод окажется помеченным как измененный?
vsb>Опять же в современных стилях стараются избегать этого самого табличного форматирования, если я правильно понял, о чём речь. В том числе и потому, что изменение одной строки может потребовать изменение ещё и 100 строк вокруг, если нужно подправить вертикальное выравнивание. Это к слову.
Если не упарываться, чтобы все было ровно всегда одинаково и для особо длинных строчек сделать исключение, то нет такой проблемы и все красиво.
А вот автоформаттер может не додуматься сделать такое исключение.
vsb>Но вопрос мне не совсем понятен. На уровне файлов это тот же git, можно посмотреть `git diff --cached` или как там его, увидишь, что там будет помечено, как изменённое в git-е. На уровне IDE это уже как авторы IDE сделают. Сделают — и метод пометят, и statement, и что угодно.
Например, я вставляю условие в начало большого метода и выход из условия в конце.
При автоформатировании, естественной во все вложенные строчки естественно, вставятся пробелы. Все будут изменены.
И нужно проследить несколько таких изменений, естественно будет каша. А такие изменения бывают часто.
Если я забью в это в случае на форматирование, которой тут может быть и не показатльны, покажет четко изменение 2 строчек.
При поддержке старых исходников, где изменения делаются редко, это критично.
vsb>Здравствуйте, swame, Вы писали:
vsb>>>Ещё хочу предложить мысль для обдумывания.
vsb>>>В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
S>>Нет. одно и тоже можно написать длиной цепочкой, или несколькими последовательными операторами.
S>>Это делает программист. Не форматтер.
S>>Если что-то сдизайнено под длинную цепочку и потом автоматом форматируется, оно становится уже совсем нечитаемым.
S>>И всякие мерджи гита на таком плохо будут работать.
S>>Я при дежживаюсь второго стиля и на своем коде форматтером не пользуюсь, он не нужен просто .
S>>Если только откуда-то достался какой-нибудь неряшливо отформатированный код и надо разобраться, тогда можно форматнуть.
vsb>Этот подход понятен, но повторюсь, в современных проектах всё чаще используется автоматическое форматирование. Это не я придумал, это можно считать уже общепринятым подходом. В том же go этот форматтер прям в поставку компилятора встроен. Если в таком проекте запушить самостоятельно отформатированный код, он просто не пройдёт валидацию и автора попросят настроить своё окружение, чтобы этого больше не повторялось.
Еще раз. То что я не юзаю автоформатирование это частный вопрос. А то что программит может написать длинный неоправданно замудренный оператор на несколько строк никакой форматтер не исправит.
Можно написать так.
if (terminal.id < 0) or ((params.IslandIndex >= 0) and (terminalInfo.Island <> params.IslandIndex)) or
(if island.TmStUpdate < params.StartTime) then continue;И автоформаттер сделает так
if (terminal.id < 0) or ((params.IslandIndex >= 0) and (terminalInfo.Island <>
params.IslandIndex)) or (if island.TmStUpdate < params.StartTime) then
continue;И не узнаешь на каком условии вышли из цикла.
А можно написать так
if terminal.id < 0 then
continue;
if params.IslandIndex >= 0 then
if terminalInfo.Island <> params.IslandIndex then
continue;
if island.TmStUpdate < params.StartTime then
continue;Разница понятна?
В моем стеке к счастью автоформатирование сделано отдельно по запросу. И настраивается.
vsb>>>И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
S>>И как я узнаю при редактировании, мои изменения будут помечены как 1 измененная строчка, или весь метод окажется помеченным как измененный?
vsb>Опять же в современных стилях стараются избегать этого самого табличного форматирования, если я правильно понял, о чём речь. В том числе и потому, что изменение одной строки может потребовать изменение ещё и 100 строк вокруг, если нужно подправить вертикальное выравнивание. Это к слову.
Если не упарываться, чтобы все было ровно всегда одинаково и для особо длинных строчек сделать исключение, то нет такой проблемы и все красиво.
А вот автоформаттер может не додуматься сделать такое исключение.
vsb>Но вопрос мне не совсем понятен. На уровне файлов это тот же git, можно посмотреть `git diff --cached` или как там его, увидишь, что там будет помечено, как изменённое в git-е. На уровне IDE это уже как авторы IDE сделают. Сделают — и метод пометят, и statement, и что угодно.
Например, я вставляю условие в начало большого метода и выход из условия в конце.
При автоформатировании, естественной во все вложенные строчки естественно, вставятся пробелы. Все будут изменены.
И нужно проследить несколько таких изменений, естественно будет каша. А такие изменения бывают часто.
Если я забью в это в случае на форматирование, которой тут может быть и не показатльны, покажет четко изменение 2 строчек.
При поддержке старых исходников, где изменения делаются редко, это критично.