Сообщение Re: Ширина кода - газетная vs книжная от 12.01.2025 15:26
Изменено 12.01.2025 15:27 vsb
Re: Ширина кода - газетная vs книжная
Ещё хочу предложить мысль для обдумывания.
В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, ну и в принципе почти в любой IDE есть подобный функционал.
И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, ну и в принципе почти в любой IDE есть подобный функционал.
И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
Re: Ширина кода - газетная vs книжная
Ещё хочу предложить мысль для обдумывания.
В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.
В современном инструментарии всё чаще используют автоматический форматтер. В последние годы во всех своих проектах я использую именно такой подход. Чем меньше свободы в форматировании кода, тем лучше. gofmt, prettier, python black, clang-format, ну и в принципе почти в любой IDE есть подобный функционал.
И вот если принять за аксиому, что код программистом никак не оформляется, а представляет из себя "жидкую" структуру, которую форматтер может на лету форматировать как душе угодно, тогда вопрос с шириной кода можно вообще отдать на откуп предпочтениям программиста. Открыл код на широком мониторе — форматтер его автоматически отформатировал хоть на 300 колонок. Открыл его в интерфейсе слияния файлов — код переформатировало в 100 символов. При этом на диске он лежит в некоем каноничном виде, и все эти переформатирования никак на это не влияют, это исключительно функционал для отображения.