80-ти символьное ограничение

Найми штурмана. ))

Мониторы стали шире, придерживаюсь ограничения в 120 символов.

А вот это, уж извините, виндузятничество. Существуют до сих пор экраны с соотношением сторон 4:3 и вы-таки считаете что все должны читать ваш код в одном единственном окне распахнутом на весь экран? Почему виндузятничество? Потому что у МС такая же примерно политика: не работает новая ОС? а вы памяти еше докупите и пару ядер к процессору...

> Код ядра может понадобиться просмотреть в консоле.

Т.е. ты свято веришь, что почти тринадцать миллионов строк кода имеют длину не более 80 символов, чтобы их можно было разглядывать в коносли?!? )))

консоли*,блин

Со смеху пальцы путаю. )))

>>Откуда в статьях взяться ограничению в 80 символов? Это ограничение пришло из допотопных терминалов и уходит корнями в перфокарты и FORTRAN.

Вообще-то ГОРАЗДО глубже :) Поинтересуйся на досуге, сколько символов в строке на обычной печатной машинке. (Ответ: обычно 80)

Допотопные терминалы почему-то их очень напоминали... Подозрительно это!

LamerOk, не тупите. Есть разные конвенции оформления кода. Конвенции оформления системного кода принимались в те времена, когда этот код писали и смотрели только в консоле.

> Существуют до сих пор экраны с соотношением сторон 4:3

а при чем тут соотношение сторон?

> Существуют до сих пор экраны с соотношением сторон 4:3 и вы-таки считаете что все должны читать ваш код в одном единственном окне распахнутом на весь экран?

У меня монитор 4:3. В Eclipse код в 120 символов в строке прекрасно видно.

Ну если ты пишешь код вообще без индентации, например на BASIC, то да, твои глаза будут уставать после 90-го символа :))

а при чем тут соотношение сторон?

При том, что если что-то стало шире, изменилось и соотношение сторон. Автор сообщения руководствовался шириной современных(читай на данный момент массово производимых) экранов.

У меня монитор 4:3. В Eclipse код в 120 символов в строке прекрасно видно.

И сколько окон у вас открыто в ширину?

ну и что? каким образом соотношение сторон монитора коррелирует с разрешением, которое только и влияет на ширину отображаемой строки?

> Код ядра может понадобиться просмотреть в консоле

Зачем?

> И сколько окон у вас открыто в ширину?

Вы о чём? Окно Eclipse максимизировано. Окно кода в нём - нет.

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

>Typography and readability, хотя это больше к печатному тексту относится, но код это всётаки тоже текст для чтения.

Цитата ...

Тема типографика и читабельность в применении к коду все равно не расскрыта. Текст в книжке это больше последовательность слов. Чтобы его понять, надо прочитать все слова подряд. Код структура древоподобная. Он часто читается вдоль одного уровня отступа, не углубляясь внутрь.

С учетом этого

55–60 characters (including spaces) per line is usually considered an appropriate line length

не надо отступы включать в длину строки. А эти 55-60 символов становятся максимально допустимым размером. Если больше, то ее стоит дробить на части.

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

Придерживаюсь, кроме как при отладке: часто делаю длинные вызовы printов.

> Давай посмотрим на вопрос со стороны глаза.

А давайте посмотрим на реальный код со стороны мозга, на код, который имеет несколько уровней вложенности, в котором переменные и фукнции имеют нормальные, говорящие, составные названия, и в этих названиях не пропускаются гласные. Итого, в середине функции что бы уместиться в ограничение в 80 символов надо размещать в одной строке одно слово. Не знаю, может глазу и хорошо, только всему остальному не очень, а растягивать одно выражение на 5-10 строк это так, что ещё попробуй разбери это одно выражение или несколько, это, извините, полный маразм.

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

Стараюсь придерживаться. И люто ненавижу править чужой код с более длинными строками, ибо в мой монитор идеально влезают два файла по 80 символов в вертикальном сплите)

Так вы выступаете даже не за 80, а за 55-60 символов в строке?

ну, можно и так сказать.

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

Т.о. 80 символов минус в среднем 2 таба дают эфективно длину строки примерно в 64 символа.

если в них нильзя уложится, то надо что-то менять в консерватории.

> ещё попробуй разбери это одно выражение или несколько

а ты пробывал переносы обозначать (ну хоть пустой комментарий в конце строки, если следующая является ее продолжением)?

> что бы уместиться в ограничение в 80 символов надо размещать в одной строке одно слово

эм...

функля_которая_принимает_пачку_аргументов_и_делает_с_ними_много_разного(аргумент_первый : Тип_который_годен_для_разного)

ты так что ли пишешь...?

>Не вызывая излишнего напряжения глазных мышц и мышц шеи, взгляд может перемещаться в пределах некоторого пространственного угла.

21 градус для среднего человеческого глаза. На дистанции 40 сантиметров это 17 сантиметров.

Чтобы символы были легко читаемы, они должны иметь достаточно большой угловой размер (т.е. учитывать надо не только линейные размеры, но и расстояние между глазом и буквой).

Оптимальны 12 пунктов на 30 сантиметров. Значит на 40 см - это будет 16 пунктов.

...

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

С учётом среднего уровня отступов в 2-4 единицы по 4 таба, получаем, что оптимальная ширина колонки 70-90 символов.

И традиционные 80 символов вписываются сюда достаточно хорошо :)

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

...

Только важно помнить, что это - _максимальная_ ширина более-менее комфортного чтения. Код же программы ещё подразумевает хорошую декомпозицию на структурные элементы - токены. Если всё лепить на всю ширину колонки - то всё равно получится write-only код :) Важно не лениться ещё и новые строчки делать, даже если код короткий получается по ширине.

ну и что? каким образом соотношение сторон монитора коррелирует с разрешением, которое только и влияет на ширину отображаемой строки?

Таким, что при одинаковой высоте 4:3 `уже нежели 16:9, и если вы намеренно не завышаете/занижаете разрешение получите меньше пикселей по горизонтали.

> Таким, что при одинаковой высоте 4:3 `уже нежели 16:9, и если вы намеренно не завышаете/занижаете разрешение получите меньше пикселей по горизонтали.

надо быть полным муд^W^W очень странным человеком, что бы строки в ширину делать на все сиюминутно-имеющееся пространство монитора.

> ты так что ли пишешь...?

Ты забыл про несколько уровней вложенности.

Вот так штоле:

DirectoryInfo dir = new DirectoryInfo(pathToDelete);

// subDirs
DirectoryInfo[] subDirs = dir.GetDirectories();
foreach(DirectoryInfo subDir in subDirs)
{
  // subSubDirs
  DirectoryInfo[] subSubDirs = subDir.GetDirectories();
  foreach(DirectoryInfo subSubDir in subSubDirs)
  {
    // subSubSubDirs
    DirectoryInfo[] subSubSubDirs = subSubDir.GetDirectories();
    foreach(DirectoryInfo subSubSubDir in subSubSubDirs)
    {
      // subSubSubSubDirs
      DirectoryInfo[] subSubSubSubDirs = subSubSubDir.GetDirectories();
      foreach(DirectoryInfo subSubSubSubDir in subSubSubSubDirs)
      {
        // ********************************************
        // should be enough; if not, I can add more here
        // ********************************************
      }

      // files
      FileInfo[] subSubSubFiles = subSubSubDir.GetFiles();
      foreach(FileInfo subSubSubFile in subSubSubFiles)
      {
        subSubSubFile.Delete();
      }

    }

    // files
    FileInfo[] subSubFiles = subSubDir.GetFiles();
    foreach(FileInfo subSubFile in subSubFiles)
    {
      subSubFile.Delete();
    }
  }

  // files
  FileInfo[] subFiles = subDir.GetFiles();
  foreach(FileInfo subFile in subFiles)
  {
    subFile.Delete();
  }
}

// files
FileInfo[] files = dir.GetFiles();
foreach(FileInfo file in files)
{
  file.Delete();
}

?

> Вот так штоле:

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

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

надо быть полным муд^W^W очень странным человеком, что бы строки в ширину делать на все сиюминутно-имеющееся пространство монитора.

Ы? Прочитали по диагонали? Не о чем таком речи в моих сообщениях и не шло.

Когда я вижу длинное выражение, мне проще перевести взгляд вправо и дочитать его на той же строчке, чем несколько раз переводить его влево и вниз. Сейчас мой монитор позволяет удобно редактировать код так, что 120 символов в строке видно. Если буду редактировать тот же код в системной консоли шириной 80 (которая у меня сейчас шириной 240 символов благодаря KMS), то редактор расположит строчки визуально одну под другой, примерно так же, как если бы я изначально пытался уложиться в 80 символов. Не вижу проблемы.

Мне удобней писать с такой максимальной длинной строки. Если кого-то это не устраивает и он не хочет читать этот код в одном распахнутом окне своего 4:3 монитора, он может либо настроить перенос строк в своем любимом редакторе, либо пройтись по коду indent'ом со своим любимым конфигом.

И увидеть виндузятничество в использовании удобства широких мониторов - это сильно =)

> (не заводить же одноразовую переменную только из-за ограничения длины строки).

Заводить, заводить. Не из-за ограничения, а из-за элементарной читабельности. Разбирать тридцать три вызова функции, которые являются аргументами друг друга - удовольствие крайне сомнительное, а «экономия переменных» - чистой воды детский сад.

> значительно более важным требованием является то, что код функции должен умещаться на одном экране

Угу. А есть еще одно требование - код функции должен быть не больше четырех уровней вложенности. (В отдельных случаях - так и трех.)

Какому ты отдашь приоритет? ;))

>Заводить, заводить.

Бритва по тебе плачет... Нафига лишние сущности?

Какие сущности?

>Угу. А есть еще одно требование - код функции должен быть не больше четырех уровней вложенности.

Ну это уже совсем.... Сама функция - 1 уровень. + она не «топ-лэвл» - ещё 1 уровень. На структуру кода осталось 2 уровня? Ну да, без 48-ми переменных не обойтись. В пень с такими правилами!

>Какие сущности?

Переменные - какие ещё

          to_ = std::auto_ptr<std::ostream>(new io::stream<io::file_descriptor_sink>(io::file_descriptor_sink(in_fd_, true)));

Ваши предложения по реорганизации кода?

>Ваши предложения по реорганизации кода?

QFile )

Ваши предложения по реорганизации кода?

не, ну тут ещё хоть так можно:

          to_ = std::auto_ptr<std::ostream>(
                    new io::stream<io::file_descriptor_sink>(
                        io::file_descriptor_sink(in_fd_, true)));

хотя и это не намного короче (и я так понимаю никаким стандартам не соответствует)

> В пень с такими правилами!

У тебя линукс? Если да, то УДОЛИЛ!! )))

man LKD CS.

> Переменные - какие ещё

Ты переменные и временные переменные совсем-совсем друг от друга не отличаешь?

> QFile

QFile здесь не поможет ;)

>У тебя линукс? Если да, то УДОЛИЛ!! )))

man LKD CS.

man фанатизм

каким боком «LKD CS» к «повседневной практике»? Мне теперь и письма бабушке писать в соответствии LKD CS, если я иногда линуксом пользуюсь? Фанатики такие фанатики...

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

>Ты переменные и временные переменные совсем-совсем друг от друга не отличаешь?

Ну давай свои определения для первого и второго, и заодно обоснование того, что вторым (а почему не первым?) в общем случае можно давать короткие имена, ничего не говорящие о сути переменной. Ах да, комментарии... Т.е. я должен помимо имени ещё таскать в голове «ассоциации», причём «в локальном контексте». Ну да, читабельность супер, но чтобы понять...

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

Я и не говорил, что это «правильный вариант», а не всего-лишь «возможный». Да, со всеми недостатками согласен

> каким боком «LKD CS» к «повседневной практике»?

Мне теперь и письма бабушке писать

Так я не понял, ты пишешь программы или письма бабушке? ))

>Так я не понял, ты пишешь программы или письма бабушке? ))

А «программы» - это теперь только ядро линукса на си?