Ранее я обещал поговорить про длинные строки кода и форматирование кода таблицей. Длинные строки сложно читать и проверять. Особенно если они уже не помещаются на экран, и приходится использовать прокрутку для их просмотра.
Пример рефакторинга длинной строки можно посмотреть в статье "Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу". Первая картинка как раз из этой заметки взята.
Ограничение на длину строк — это один из примеров, что можно включить в стандарт кодирования.
Заметить опечатку мешают не только длинные строки, но и неаккуратно отформатированные. На второй картинке пример функции из проекта Apache Flink.
Видите ошибку? Поскольку вы знаете, что она здесь есть, думаю, вы её найдёте. А вот не зная об этом, сомнительно, что вы сможете сохранить внимание при изучении этого кода в процессе обзора и найти её. Собственно, разработчики ошибку и не нашли, раз мы её здесь изучаем.
Ошибка найдена с помощью статического анализатора кода PVS-Studio: V6001 There are identical sub-expressions 'processedData' to the left and to the right of the '==' operator. CheckpointStatistics.java(229)
Вот она:
processedData == processedData
Переменная сравнивается сама с собой. Хотя ошибка найдена, лучше заниматься не её поиском, а профилактикой. Если оформить код более красиво (таблицей), как показано на третьей картинке, ошибка более заметна.
Конечно, это не гарантирует, что ошибка не будет пропущена. Речь о том, чтобы снизить вероятность её допустить и просмотреть на обзорах кода.
Чтобы расставлять меньше пробелов и реже переформатировать код, лучше ещё доработать стиль оформления: см. рисунок 4.
Объяснение, чем такой вариант лучше, выходит за рамки поста. Предлагаю вашему вниманию эту заметку "Форматирование кода таблицей", где это момент объясняется на примерах.
Форматирование кода таблицей не обязательно станет тем, что вы должны включить в свой набор правил кодирования. Это просто пример, что можно почерпнуть из книги и внедрить. Можно найти и другие источники для вдохновения.
Внедрение стандарта кодирования повысит общий уровень вашей разработки, что положительно повлияет на безопасность разрабатываемых приложений. Так что меры, перечисляемые в ГОСТ Р 56939-2024, имеют ценность в практической плоскости.
Дополнительно можно настроить и использовать инструменты автоматизированного форматирования кода, такие как: