80 строк и 25 столбцов были измерениями одного из самых популярных текстовых режимов VGA в 1980-х и 90-х годах. Сегодня у нас на наших 24-дюймовых мониторах гораздо более мощные графические карты, которые воспроизводят несколько мегапикселей каждую секунду.
Тем не менее, я бы сказал, что типичному программисту для просмотра кода не требуется более 80×25 окон с фиксированной шириной символов . Мои меры для кода PHP, но если вы измените фактические числа, фиксированные измерения могут работать и с вашим кодом Java или Ruby.
Если вы знакомы с IDE, экранная область может использоваться для отображения другой полезной информации и избегать переключения контекста, такого как список доступных методов, дерево папок и файлов или ваша красная / зеленая полоса. Я сам держу другой терминал открытым с моим запущенным Vim для выдачи команд управления версиями (хотя я могу интегрировать это в окно Vim в будущем).
ширина
Так почему же терминалы 80х25? Эти меры могут показаться ограничением, но на самом деле многие методы программирования основаны на ограничениях. Например, структурированное программирование (если, в то время как) ограничивает вас от прыжков в вашем коде. Частные и защищенные области для ваших учеников ограничивают доступ к ним. Ограничения не так уж и плохи, если они заставляют вас упростить вашу математическую модель реальности (то есть вашу кодовую базу).
Ограничение в 80 символов определяет строки, которые слишком длинные, чтобы их можно было быстро понять . Некоторые IDE (например, Netbeans) могут отображать красную линию на пределе 80 символов, чтобы показать вам, превышаете ли вы его (я думаю, что это число, конечно, настраивается). Мой Vim отображает красный фон на отрезках линий после. 81 персонаж.
Инструменты статического анализа, такие как PHP_CodeSniffer, объединяют стандарты кодирования, которые отображают предупреждение, когда строка слишком длинная, и ошибку, когда она действительно слишком длинная (более 120 символов в стандарте Zend ):
if (!$this->getParam('noViewRenderer') && !Zend_Controller_Action_HelperBroker::hasHelper('viewRenderer')) {
require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';
Zend_Controller_Action_HelperBroker::getStack()->offsetSet(-80, new Zend_Controller_Action_Helper_ViewRenderer());
}
В каком состоянии? А что происходит в строке 3? Мне сложно сказать с первого взгляда.
Если вы сделаете строки короткими, читатели кода смогут следить за ходом процесса, почти всегда перемещаясь в вертикальном направлении, без необходимости исследовать горизонтальное измерение и не сопоставлять начало строк с концом других строк. Опять же, IDE могут свидетельствовать о выбранной вами строке, чтобы вы не потеряли свое место, но я уверен, что при чтении кода вы не будете постоянно перемещать курсор на строку, которую вы сейчас читаете.
Высота
Мера 25 обнаруживает слишком длинные методы : когда вы обнаруживаете, что непрерывно перемещаетесь вверх и вниз по окну просмотра из 25 строк, чтобы понять, что делает метод, есть вероятность, что он уже слишком длинный.
Фактически, предел для идеальной длины метода, вероятно, установлен на еще более низком показателе, например 6-10 строк, согласно дяде Бобу. Однако у меня нет абсолютных показателей, поскольку длина методов зависит от краткости используемого вами языка программирования: Java и Python действительно разные, и метод из 6 строк в Python может соответствовать большей, более длинной версии в Ява. В Matlab этот же метод, вероятно, будет в два раза длиннее.
В разных языках программирования ограниченное окно просмотра не позволяет программистам писать и поддерживать длинные методы . Если вы можете настроить высоту окна до 2000 пикселей, вы никогда не будете касаться 100-строчного метода, который заставит вас полностью прокрутить 4 раза, чтобы прочитать все это.
Рассмотрим регионы : некоторые IDE позволяют вам определять специальные комментарии, которые действуют как навигационные указания. Если вам нужны регионы для навигации в классе, этот класс уже слишком длинный, на мой вкус. Вместо этого может быть полезно сложить методы, но когда вы открываете метод, он все равно должен быть короче, чем ограничение в 25 строк.
вдавливание
Я также являюсь поклонником другой меры эквивалентности, которой являются 4 пробела для одной вкладки (в общем, для одного уровня отступа). Я не вступаю в войну против табуляции и религии , но я думаю, что уровни отступа действительно читабельны, если они представлены 4 пробелами или символом табуляции, визуализируемым с шириной 4 пробелов. 4 пробела также является стандартом Python (если не используются вкладки).
Альтернативные варианты отступа: 2 пробела на уровень и 8 пробелов на уровень.
2 пробела , вероятно, слишком мало, чтобы легко обнаружить отступы, особенно если вы программируете пару и просматриваете код с перекосом (если вы используете пару с двумя экранами, это хорошо для вас).
8 пробелов на мой взгляд, вероятно, слишком много; если вы работаете с объектно-ориентированным программированием, как многие из нас, вы уже начинаете писать большую часть своего кода с двумя уровнями отступов (класс и метод). Если вам нужно написать строку в цикле, вы получите только 55-56 символов для вашей строки.
Таким образом, 4 пробела легко обнаружат слишком много уровней отступов в одном и том же методе, что является признаком метода, который объединяет много разных уровней абстракций ; в то же время они позволят вам использовать два вложенных цикла, например, для доступа к двумерному массиву (например, к изображению).
class MyClass {
public void doSomething(Image image) {
for (int x=0; x < height; x++) {
for (int y=0; y < width; y++) {
doSomethingWithPixel(image.at(x, y)); //this line: 80 characters
// why would you need a longer one?
}
}
}
}
Выводы
По этим причинам я чувствую себя комфортно с окнами 80×25 и шириной отступа в 4 пространства. Что вы используете вместо этого? Максимальное затмение на 30-дюймовом мониторе? 2 пробела, как в стандарте кодирования Symfony 1? Почему вы находите это полезным?