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

Большинству редакторов / IDE придется согласиться на сохранение кода в одном и том же стандартизированном представлении, которое зависит от языка, но после этого есть много преимуществ.

Стандартизированное представление, вероятно, будет текстовым и допустимым компилируемым кодом, чтобы он был удобочитаемым для человека, и все существующие инструменты по-прежнему работали.

Велосипедов нет

Не нужно никакого велосипеда, не нужно обсуждать, использовать ли табуляции или пробелы, точки с запятой или скобки.

Вам не нужно согласовывать максимальную длину строки или предпочтительную длину строки, и длина строки может зависеть от текущего размера окна вашего редактора.

Команде не нужно согласовывать, какой форматировщик кода использовать или его настройки. Руководства по стилю не нужны (по крайней мере, для форматирования и пробелов).

Авторам инструментов автоматического форматирования не нужно добиваться широкого консенсуса, что часто является предметом горячих споров.

Вместо этого каждый член команды может выбрать для просмотра код в любом формате, который он предпочитает, если его поддерживает редактор/инструмент автоматического форматирования.

Никаких пробелов или изменений форматирования в Git

Поскольку мы сохраняем стандартизированное представление, никакие пробелы или изменения форматирования не сохраняются.

Это, в свою очередь, означает, что эти изменения не отображаются в различиях Git, что упрощает просмотр и снижает вероятность конфликтов.

Кроме того, если вы просматриваете/просматриваете различия в своем редакторе (или в чем-то еще, что его поддерживает), то вы можете увидеть изменения в любом удобном для вас формате.

Стандартное представление можно оптимизировать для Git.

Поскольку стандартизированное представление в основном используется компьютером, мы можем оптимизировать его для дальнейшего улучшения различий Git и снижения вероятности конфликтов.

Стандартизированное представление может располагать код вертикально, со всем на отдельной строке.

С приведенным ниже макетом кода один человек мог редактировать имя функции, а другой мог добавлять/удалять/переименовывать параметр, и изменения происходили в разных строках. Это облегчает обнаружение в diff и не вызывает конфликта слияния.

Обычно люди предпочитают видеть такой код написанным в одну строку, что вызывает конфликт, если один человек редактирует имя функции, а другой добавляет/удаляет/переименовывает параметр.

Вы можете использовать компактный формат для обзора

Когда вы впервые читаете большой файл, вы можете использовать компактный формат, чтобы увидеть больше кода на каждой странице и, возможно, даже увидеть его весь на одной странице. Этот формат может показывать минимальное количество пробелов и максимально группировать код в одной строке, а также потенциально делать более агрессивное форматирование, например:

  • Скрыть код обработки ошибок/исключений, чтобы выделить правильный путь
  • Скрыть тела функций/параметры для просмотра действительно высокого уровня
  • Просто покажите код jsx в React, чтобы выделить древовидную структуру компонентов.
  • Используйте более крупный шрифт, чтобы выделить имена функций
  • Замените операторы Haskell (fmap, apply, mappend и т. д.) эквивалентными символами (<$>, <*>, <> и т. д.)

Код ниже был первоначально длиной 90 строк, но если мы используем компактный формат и спрячем код обработки исключений, он может быть показан в 35. Если мы действительно агрессивны с пробелами, это может даже сократиться до 25.

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

Вы можете использовать расширенный формат для деталей

При разработке и особенно при отладке часто необходимо разбираться в каждой мелочи кода, и для этого полезно использовать расширенный формат. Много раз я упускал важный нюанс кода только потому, что код было трудно сканировать и мой глаз что-то пропускал, или что-то не видел.

Если мы используем расширенный формат, мы можем упростить сканирование кода и сделать так, чтобы было трудно упустить какую-либо деталь. Код занимает намного больше места на экране по вертикали, но обычно это нормально, так как мы будем рассматривать только небольшой участок кода.

Приведенный ниже код делает очевидным, что DesignTurbulence вычисляется, но особенности вычисления труднее прочитать.

Если мы используем расширенный формат, гораздо легче увидеть, что происходит и какие скобки совпадают. Формат может даже добавлять скобки и отступы, чтобы сделать приоритет операций очевидным в тех случаях, когда это важно. В приведенном ниже формате к 1.28 / windSpeed * 1.44 добавлены скобки и отступ, так как оператор деления имеет более высокий приоритет, чем оператор умножения, что можно легко пропустить или забыть при просмотре более компактного формата.

И редактор может даже показать этот код в математическом формате, который большинству людей кажется более понятным. Это также облегчит сверку кода с исходным расчетом, когда оригинал отображается в том же формате (что является распространенным).

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

Визуальный поток может соответствовать логическому потоку

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

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

Есть много других случаев, когда это было бы полезно.

Выражение if / else может отображать обе ветви рядом, возможно, с ветвью true, отображаемой слева (при условии, что true является преобладающим случаем). Операторы case могут разветвляться горизонтально, когда есть место. Циклы for могут отображать начальное значение, конечное условие и условие повторения в формате блок-схемы, что упростит обнаружение ошибок, идущих один за другим. Аналогичные вещи можно сделать для while и других циклов.

В приведенном ниже примере показано, как может выглядеть функция бинарного поиска в Python:

Языки справа налево

Строка является изограммой, если она содержит не более одной буквы каждой буквы, и приведенный ниже код Haskell вычисляет это.

В Haskell поток кода идет справа налево, что сбивает с толку людей, которые к этому не привыкли, и большинству читателей слева направо будет легче понять, как работает приведенный ниже код. Это недопустимо в Haskell, но нет причин, по которым редактор не мог бы отобразить это таким образом.

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

Функциональное программирование

Я большой поклонник функционального программирования, как и многие люди, изучающие его. Когда код компилируется и работает, он часто получается очень элегантным, выразительным и легко читаемым даже для новичков. Однако, если это не работает, мне иногда трудно понять, в чем проблема, и новичкам определенно может быть сложно писать.

Если вы не знакомы с функциональными парадигмами и функцией converge из rambda, невозможно понять, что делает этот код.

Однако, если редактор знает о функции конвергенции или может следить за потоком функций, он может отобразить такой код.

Это делает поток кода сразу очевидным и выделяет любые проблемы. В этом примере теперь ясно, что firstName и lastName должны быть функциями, принимающими один параметр объекта, и что функция compliment должна принимать два параметра. Мы также можем легко проверить, что типы, возвращаемые функциями firstName и lastName, соответствуют типам, ожидаемым compliment.

Заключение

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

Существует также возможность пойти на полпути и использовать форматирование по запросу, но без сохранения в стандартизированное представление. Это значительно упрощает внедрение, поскольку вы можете попробовать его без каких-либо обязательств, не затрагивая остальную часть команды, и только инструмент, который вы используете, должен его поддерживать. Вы по-прежнему получаете много преимуществ и просто упускаете возможность оптимизации git. JetBrains MPS стоит посмотреть в этом пространстве.