«Рекомендуемая» длина файла и ширина строки [закрыто]

Мне было бы любопытно, если бы кто-нибудь знал о рекомендации из авторитетного источника для максимального количества строк кода для данного файла. Например, Google Closure Linter рекомендует, чтобы каждая строка не превышала 80 символов.

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

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

Такой вещи не существует, и если бы она существовала, это было бы в значительной степени зависеть от того, какой язык вы используете (например, в ассемблере по сравнению с C # или Java).

Для языков более высокого уровня вы можете увидеть это обсуждение SO. Для Java / C # 10-20 строк на метод - это то, что Боб Мартин рекомендует как максимум. Там нет обсуждения относительно файлов, так как это не имеет отношения к делу и зависит от того, что должен делать класс.

Что касается ограничения на 80 символов в строке - это возврат ко дням перфокарт. Сказав это, когда строки становятся слишком длинными, читаемость страдает.

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

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

Длинные строки указывают на то, что выражения слишком сложны.

Это запахи, которые указывают на потенциальную проблему с кодом, а не на четко определенные целевые показатели.

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

Методы и функции лучше всего подходят для одного экрана.

Файлы не должны быть слишком длинными. Лучшими являются короткие файлы, в которых легко понять класс и реализацию.
Однажды я работал над проектом, который имел файл 10 klines. Это было похоже на чтение очень сложной книги. Нужно ли мне сказать, сколько проблем вызвало внедрение?

80 персонажей!

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

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

Я стараюсь держать классы и методы короткими, но не очень беспокоюсь о длине строки. В наши дни широких экранов и длинных идентификаторов, я думаю, восемьдесят символов - это слишком мало. Требуется некоторая работа, чтобы разбить операторы, чтобы их было легко прочитать, и с ограничением в восемьдесят символов это происходит довольно часто. Я думаю, что около 120 или 130 столбцов в строке более разумно.