Стандарт форматирования ширины линии

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

Поэтому я говорю: как всегда, оставьте 70-80 символов. Большие экраны просто означают, что в IDE больше места.

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

Я придерживаюсь правила 80 строк (и пытаюсь убедить всех сделать то же самое). Некоторые причины:

1. Вы можете открыть 2 (или более) редактора одновременно.
2. То же самое и с инструментами сравнения. - большинство (все?) из них отображают два (некоторые три (некоторые больше?)) файла рядом.
3. Иногда вам нужно работать удаленно, на другой рабочей станции или ноутбуке, и внезапно ваш красиво отформатированный код из 120 символов в строку выглядит ужасно.

Мы используем стандарт кодирования из 80 символов в строке. Первоначальная причина ограничения 80 символов сегодня не актуальна, но следует указать какое-то число ...

Помимо очевидного (организация кода и удобочитаемость), обычно я обнаруживал, что длинные строки являются результатом плохого стиля, и следование этому правилу улучшает качество кода и уменьшает количество ошибок. Просто сравните следующие примеры:

status = do_something(); 
if (status == error)
{
    do_error_handling();
    return;
} 
/* do you regular flow */
status = do_more();
if (status == error)
{
    do_error_handling();
    return; 
}
/* do more of you regular flow  and keep you line 80 chars*/

вместо :

status = do_something(); 
if (status == succes)
{
     /* do you regular flow */
     status = do_more();
     if (status == success)
     {
            /* do you regular flow */
            /*  nest again and get line behind visible screen */
     }
     else
     {
         /* do error handling */ 
     }

}
else
{
     /* do error handling */ 
}

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

Редактировать

Заменил goto на do_error_handling() в коде, чтобы избежать неактуального обсуждения.

Как я уже говорил, 80 символов сегодня не актуальны, просто число 100 тоже хорошо.

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

Большой экран - крупный шрифт. Я использую GVim с Conslas 14pt с максимальным разрешением экрана 1280x800. Пытаюсь обернуть примерно на 80-90% ширины экрана.

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

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

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

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

Я делаю это в документах .txt, а также в .c, .java, .cpp, пакетных файлах и т. д. Это упрощает отправку фрагментов по электронной почте, публикацию в блогах, добавление комментариев и т. д. сразу под верхней строкой, определяющей файл и формат текста:

/* example.txt 0.00                  UTF-8                   dh:2008-11-09
*---|----1----|----2----|----3----|----4----|----5----|----6----|----7----*
*/

Конечно, используется соглашение о комментариях к конкретному типу файла.

Не ставьте под угрозу читаемость догматических правил о точном количестве символов в строке. Горизонтальная прокрутка нежелательна, но строку из 81 символа легче читать, чем версию с запутывающими отступами строками.

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