Содержимое файлов не должно превышать 80 колонок
Все классы, которые мы написали на данный момент, были достаточно простыми, чтобы мы могли реализовать функции-члены непосредственно внутри определения самого класса. Например, вот наш вездесущий класс Date :
Однако по мере того, как классы становятся длиннее и сложнее, наличие всех определений функций-членов внутри класса может затруднить управление классом и работу с ним. Использование уже написанного класса требует понимания только его открытого интерфейса (общедоступных функций-членов), а не понимания того, как класс работает под капотом. Детали реализации функций-членов просто мешают.
К счастью, C++ предоставляет способ отделить часть «объявления» класса от его «реализации». Это делается путем определения функций-членов класса вне определения класса. Для этого просто определите функции-члены класса, как если бы они были обычными функциями, но добавив к функциям префикс из имени класса с помощью оператора разрешения области видимости ( :: ) (так же, как для пространства имен).
Вот наш класс Date с конструктором Date и функцией setDate() , определенными вне определения класса. Обратите внимание, что прототипы этих функций всё еще присутствуют внутри определения класса, но фактическая реализация вынесена за его пределы:
Это довольно просто. Поскольку функции доступа часто представляют собой только одну строку, они обычно остаются в определении класса, даже если их можно переместить за его пределы.
Вот еще один пример, который включает внешний конструктор со списком инициализации членов.
Помещение определения класса в заголовочный файл
Из урока, посвященного заголовочным файлам, вы узнали, что вы можете помещать объявления функций в заголовочные файлы, чтобы использовать эти функции в нескольких файлах или даже в нескольких проектах. Классы ничем не отличаются. Определения классов можно помещать в заголовочные файлы, чтобы упростить их повторное использование в нескольких файлах или нескольких проектах. Традиционно определение класса помещается в заголовочный файл с тем же именем, что и класс, а функции-члены, определенные вне класса, помещаются в файл .cpp с тем же именем, что и класс.
Вот снова наш класс Date , разбитый на файлы .cpp и .h :
90 рекомендаций по стилю написания программ на C++
Ничего не понял, в чём проблема? Отличить конструктор от метода? помоему это очевидно и с именем никак не пересекается.
и потом, допустим, должно быть SomeClass::Method(), но при этом someClass.method(); же, что еще больше путаницы создает.
в чём конкретно? что трудно различить SomeClass::Method() и SomeClassObj.Method()? А :: и. не помогут? К тому же я вообще ни разу не встречал ситуации когда статический метод и обычный были с одинаковым именем.
Параметры по умолчанию
Параметры по умолчанию для функций-членов должны быть объявлены в определении класса (в заголовочном файле), где они могут быть видны всем, кто включает заголовок.
Похожие вопросы
90 рекомендаций по стилю написания программ на C++
Итак, что я должен определять в файле заголовка, а что в файле .cpp ,и что внутри определения класса, а что вне его?
У вас может возникнуть соблазн поместить все определения ваших функций-членов в заголовочный файл внутри класса. Хотя это будет компилироваться, у этого подхода есть несколько недостатков. Во-первых, как упоминалось выше, это загромождает определение вашего класса. Во-вторых, если вы измените что-либо в коде в заголовке, вам придется перекомпилировать каждый файл, который включает этот заголовок. Это может иметь волновой эффект, когда одно незначительное изменение вызывает необходимость перекомпиляции всей программы (что может быть медленным). Если вы измените код в файле .cpp , необходимо будет перекомпилировать только этот файл .cpp !
Поэтому мы рекомендуем следующее:
- классы, используемые только в одном файле, и которые, как правило, нельзя использовать повторно, определяйте непосредственно в том файле .cpp , где они используются;
- классы, используемые в нескольких файлах или предназначенные для повторного использования, определяйте в файле .h с тем же именем, что и класс;
- тривиальные функции-члены (тривиальные конструкторы или деструкторы, функции доступа и т.д.) могут быть определены внутри класса;
- нетривиальные функции-члены должны быть определены в файле .cpp с тем же именем, что и класс.
В будущих уроках большинство наших классов будет определено в файле .cpp , а все функции будут реализованы непосредственно в определении класса. Это сделано для удобства и для краткости примеров. В реальных проектах классы гораздо чаще помещаются в их собственные исходные и заголовочные файлы, и вы должны привыкнуть к этому.
Популярные теги
У меня есть mp3-песни с качеством звука 320 кбит /с. Общий размер песен составляет около 200 МБ с общим игровым временем около 150 минут.
Могу ли я записать эти песни на аудио CD, характеристики которого следующие:
- 52-кратная скорость записи на записывающем устройстве CD-R /RW
- Объем хранения 700 МБ равен 80 мин. Время записи музыки
Вы можете записать 200 МБ на диск 700 МБ, если диск остается диском данных.
Если вы хотите, чтобы компакт-диск воспроизводился в домашних аудиосистемах /стереосистемах, тогда файлы MP3 будут декодироваться на необработанные PCM (например, WAV-файл) во время процесса записи, и диск будет записан с использованием «основанного на времени» вычисления и ваши 150 минут не подойдут.
700 МБ вычисляется до 80 минут в формате CDDA ( Compact Disc Digital Audio ). То, что вы попросили, немного неоднозначно, вот что вы можете просить:
Вы можете записать 80 минут музыки (где MP3 переформатирован на CDDA, который вы можете прослушивать на большинстве проигрывателей компакт-дисков)
Вы можете записать 700 МБ музыки (где MP3 записан как таковой - как данные, а не как аудио), и вы можете воспроизводить только на CD игроки, которые распознают формат MP3, помните, как данные, а не как аудио)
Но вы определенно и абсолютно не можете записать 700 МБ и 80 минут MP3. 700 МБ (цифровой формат) равен количеству «аналоговых» (аудио) минут.
Вы должны помнить, что MP3 является аудио-цифровым форматом, где 320 кбит /с (или 128 кбит /с, или 256 кбит /с и т. д.) является образцом для каждого «х» МБ исходного оригинала (в основном, формата CDDA) и используется в настоящее время для потока.
Итак, вы должны выбрать, какой формат вы будете использовать. Если у вас слишком много файлов для записи, используйте MP3 (записывайте как данные), но вы будете ограничены ПК, автомобильными радиоприемниками или проигрывателями компакт-дисков в совместимом формате, но если у вас есть несколько файлов (всего не более 80 минут от общего количества время воспроизведения), вы можете записать его как аудио, чтобы вы могли иметь большую совместимость со стандартными игроками.
Дополнительный FYI: тот факт, что вы можете записать MP3 на компакт-диск, не означает, что ваш MP3-файл «мастеров» сам по себе. Вы получите то же качество звука на своем аудио CD, как было записано в исходном источнике MP3 (будь то библиотека или другая библиотека).
Метка «700 МБ /80 Мин» описывает два очень разных способа записи компакт-диска.
Компакт-диск можно записать как диск Data или как диск Аудио .
700 МБ для версии данных . 80 Min для версии аудио .
Когда вы записываете компакт-диск в качестве компакт-диска Аудио , он будет соответствовать 80 минутам музыки. Это ограничение стандартизировано, и вы не можете портить музыку, чтобы изменить это. Это будет так много и не больше, независимо от того, что вы делаете с качеством своей музыки.
Если вы записываете диск как компакт-диск Data , тогда ограничение становится только 700 МБ. Продолжительность не имеет значения. Если вы кодируете свой собственный MP3 для ток-шоу или аудиокниг, вы можете легко выполнить сжатие 1 час /10 МБ, давая вашему 700 МБ диск колоссальную 4200 минут (70 часов).
Для максимальной совместимости аудио компакт-диск будет работать в любом проигрывателе, совместимом с носителями CD-R, что означает большинство игроков, построенных в 21 веке. Воспроизведение MP3 не обязательно присутствует во всех системах, даже в новых.
Да, это можно сделать. Но это вряд ли то, что вы хотели бы сделать.
CD содержит 80 минут стереозвука. Но стерео означает, что есть два канала. Если вы хотите стать творческим, вы можете закодировать половину своей коллекции как моно в одном канале, а половину коллекции - моно в другом канале. Затем, в вашем проигрывателе компакт-дисков, панорамируйте весь путь, чтобы прослушать один канал, и все в порядке, чтобы прослушать другой канал.
Это, конечно, довольно сложно. Я предполагаю, что вы захотите, чтобы каждый файл был отдельным треком, поэтому вам нужно будет сопоставить похожие длины и, вероятно, смириться с некоторой тишиной на одной стороне, когда песня на другом канале завершится. Возможно, вы сможете играть с несколькими дорожками на песню /файл, если вы используете опцию «диск одновременно» на вашем CD-рекордере, чтобы устранить любой пробел между дорожками.
Там не будет никакого программного обеспечения, которое поможет вам в этом. Вам просто нужно использовать аудиоредактор для создания монохромных композиций, а затем объединить их в один файл на дорожку, а затем записать этот файл как аудио на ваш диск.
Таким образом, хотя это технически можно сделать, это сложно сделать и дает худший результат, который имеет только монофонический звук и требует CD-плеер с управлением панорамированием (или отключением динамика).
Лучше всего посмотреть, работает ли MP3-плеер (например, просто записывать MP3-файлы в виде файлов, а не аудио), или просто создавать два компакт-диска.
Зависит от способа его записи.
Есть два способа сделать это:
- Если вы хотите записать его как классический Audio CD , с одним сессии, которую вы можете играть во ВСЕХ стереосистемах с драйвером CD, вы не сможет сжечь его, потому что таким образом аудио продолжительность будет рассмотрена и 150 минут аудио не поместится на ней.
- Если вы хотите записать mp3-файл (сам файл) внутри диска, вы сможете это сделать! Он превратит CD-ROM с 200 МБ .mp3 файл сгорел внутри него. Старые системы НЕ ПРОЯВЛЯЮТСЯ играть в mp3 файлы компакт-дисков, но в настоящее время все системы могут воспроизводить его.
Итак, если вы уверены, что система является современным устройством, напишите mp3-файл на компакт-диске. Это будет зависеть от используемого вами программного обеспечения для записи, но в Windows вы можете просто скопировать и вставить файл внутри устройства CD через «Мой компьютер» и записать его.
Вы можете поместить 150 минут монофонической музыки на один звуковой компакт-диск, если вы поместите первые 75 минут в левый канал, а остальные 75 на правой стороне, чтобы подделать его на 75 минут стерео.
Очень неудобно слушать, так как вам нужно отключить один из ваших динамиков. И вы потеряете стерео. И не приятно в наушниках, если вы не слушаете друга, у которого другой вкус в музыке, поэтому вы можете слушать один и тот же диск, но с другой музыкой, хотя и с одной стороны наушников. Или используйте сплиттер.
В зависимости от музыки на самом деле может быть улучшением конечного результата;)
(Стандарт для CD - стерео - никоим образом не обойти это)
90 рекомендаций по стилю написания программ на C++
Вообщето такое возможно но мало вероятно.
SomeClass *lv_Obj = 0; lv_Obj->DoSmth(); // функция вызовется и если внутри нет обращения к полям то ещё и успешно выполнится.
но вообще так писать разуметься не хорошо, а если уж и пишешь то следует писать
if (!this) return;
ибо ненужные скоупы это тоже плохо.
Похожие вопросы
Не нарушает ли определение класса в заголовочном файле правило одного определения?
Не должно. Если ваш заголовочный файл имеет надлежащие средства защиты заголовка, то не должно быть возможности включить определение класса более одного раза в один и тот же файл.
90 рекомендаций по стилю написания программ на C++
90 рекомендаций по стилю написания программ на C++
Что и? проблема в том что это можно сделать, и это может повлечь не очевидную проблему (злая шутка)
Поэтому писать 0 всё же лучше, а с точки зрения читаемости это ничего не поменяет.
Не нарушает ли определение функций-членов в заголовке правило одного определения?
По-разному. Функции-члены, определенные внутри определения класса, считаются неявно встраиваемыми (inline). Встраиваемые (inline) функции освобождаются от правила одного определения относительно одного определения в программе. Это означает, что нет проблем с определением тривиальных функций-членов (таких как функции доступа) внутри определения самого класса.
Функции-члены, определенные вне определения класса, обрабатываются как обычные функции и подчиняются правилу одного определения относительно одного определения в программе. Следовательно, эти функции должны быть определены в файле исходного кода, а не внутри заголовка. Единственным исключением являются шаблоны функций, о которых мы поговорим в следующей главе.
Популярные теги
90 рекомендаций по стилю написания программ на C++
Позволяет легко отличать переменные от типов, предотвращает потенциальные коллизии имён, например: Line line;
Всегда думал что наилучший подход в данном случае использовать префиксы видимости (хоть они и не очень нравятся), они очень хорошо помогают в условиях современных IDE с интелесенсом, и при чтении, сравни:
6. Названия методов и функций должны быть глаголами, быть записанными в смешанном регистре и начинаться с нижнего.
Зачем? при этом ведь возможен конфликт имён, и из-за этого тебе потом приходится ставить постфикс в приватных переменных, лучше с большой буквы т.к. это в любом случае будет выглядеть лучше
SomeObj.Method() // гармония SomeObj.method() // дизгармония
Логика тоже неясна. Зачем дробить понятие наименование на такие группы? когда конфликты в случае namespace, class name, func name. практически никогда не происходят, гораздо лучше задать им единый стиль.
SomeNamespace::SomeObj.Method() // гармония some_namespace::SomeObj.method() // дизгармония
8. Следует называть имена типов в шаблонах одной заглавной буквой.
Это самый вредный совет который только можно было придумать, параметры шаблона, равносильны параметрам функции, тыже небудешь делать в функции такие параметры: void SomeFunc(int A, int C, int B, char* T)
Не имеет смысла аббревиатуры на то и аббревиатуры что имеют определённый стиль написания, и менять его не следует.
Суффиксы самая бессмысленная вещь, либо префиксы либо без них. Если приватное имя, и имя параметра будут совпадать, то будет очень легко допустить ошибку при наборе + интелесенс поможет сделать ошибку, а при чтении суффикс _ вообще будет незаметен. Вредный совет.
Не логично, имя на то и имя что должно характеризовать назначение объекта, в большинстве случаев имена параметров и собственных типов совпадает, но когда используются посторонние типы или стандартные, совет выглядит глупым.
SomeFunc(string& stringPath, int CountInt, float OffsetFoloat)
Зачем повторять тип когда IDE сама подскажет?
14. Переменные, имеющие большую область видимости, следует называть длинными именами, имеющие небольшую область видимости — короткими.
название пункта звучит очень гупо. Надо было сказать про стандартное допущение при наименовании итераторов в циклах.
Довольно спорный момент, get/set это так называемые свойства, которые в других языках реализованы обычным именем свойства без get/set, да и без get/set облегчается рефакторинг.
В идеале читающий вообще не должен знать что происходит внутри, идёт там вычисление или значение из кэша достаётся.
Почему? Многие сокращения являются общепризнанными, например Avg, Min, Max, Sin, Cos, Cmd, Init и т.д. зачем перегружать названия и делать их длинными когда в некоторых случаях это не несёт смысла.
Такие символы вызывают ряд проблем, связанных с редакторами, эмуляторами терминалов и отладчиками, используемыми в программах для совместной разработки и кроссплатформенных средах.
51. Символ указателя или ссылки в языке C++ следует ставить сразу после имени типа, а не с именем переменной.
Глупость, в стандарте С++ и С нет особого типа bool который необходим для условий, соответственно не имеет смысла писать
if (nLines != 0) // в С++ это равносильно if (nLines != false)
58. Следует избегать использования break и continue в циклах.
Такие выражения следует использовать только тогда, когда они повышают читаемость.
Неужели может попробуешь скомпилировать код с функцией без типа возврата? Такое допускается, только с main и то выдаёт ошибку.
72. Блоки кода следует оформлять так, как показано в примере 1 (рекомендуется) или в примере 2, но ни в коем случае не так, как показано в примере 3. Оформление функций и классов должно следовать примеру 2.
О да, 1 и 2 являются одним из вечных источников холиваров K&R или Олман в области стиля. И гайдлайн который вроде бы должен как раз такие моменты разруливать включает оба этих момента, круто!
ты же говорил что так
if (a == lowValue) compueSomething(); else if (a == mediumValue) computeSomethingElse(); else if (a == highValue) computeSomethingElseYet();
нельзя делать, плохо когда в гайдлайне существуют расхождения.
В общем очень, очень плохая статья. Многое писал КЭП, много вредных советов, много спорных моментов, много бессмысленных советов, много не освещённых моментов (например макросы, шаблоны, вложенные классы, датахолдеры, употребление explicit, перегрузка операторов, абстрактные классы(они же интерфейсы) ). Очень многое можно выкинуть и упростить.
Хочется посмотреть, кто как код форматирует. Накидайте пожалуйста следующий код, отформатированный по вашему вкусу:
Я думаю, этому пациенту форматирование не поможет.
Всего лишь открывающую фигурную скобку с новой строки и не 4 пробела, а 1 таб размером 4.
сopy_seq_loop вообще монстр.
Не влазит в 80 строк же :) И чит с typedef позволил тебе не переносить аргументы на новую строку, давай без него.
Самое неоднозначное - как бить строки в итоге и не видно из твоего примера.
Всё прекрасно влазит: 78 столбцов, 14 строк :3
Самое неоднозначное - как бить строки в итоге и не видно из твоего примера.
Вот так и бить: используя возможности языка, предназначенные для повышения удобочитаемости. Это не чит же.
Но если б я был упорот, то вместо
Ну про «чит» это в контексте топика, когда главное это форматирование, ведь с любыми ухищрениями рано или поздно строки бить придется, вот и хотелось увидеть как.
Спасибо за участие в смотрах :)
PS. без «template» перед call не заведется
между раздельными сущностями (функциями) делать пропуск в 1 строку, а то каша какая-то
За компилябельность не ручаюсь, но я обычно пишу как-то так.
Это, если без typedef'ов. Но такое без них писать — плохо, как ни оформляй.
ставлю в редакторе 120 символов в ширину, и плюю на ограничения перфокарт и CGA-мониторов с высоты 2014 года.
Почему 80 символов являются «стандартными» ограничениями для ширины кода? Почему 80, а не 79, 81 или 100? Каково происхождение этой особой ценности?
Вы можете поблагодарить IBM перфокарты для этого предела - у него было 80 столбцы:
Как упоминалось oded , этот общий стандарт кодирования является результатом 1928 года IBM 80 формат столбчатой карточки , поскольку многие стандарты кодирования относятся ко времени, когда программы были написаны на перфокартах, одна карта /line за раз, и даже переход на более широкие экраны не изменил того факта, что код становится сложнее читать, чем шире он становится.
На странице wikipedia на перфокарта s:
90 рекомендаций по стилю написания программ на C++
Библиотеки
Разделение определения и реализации класса очень распространено для библиотек, которые вы можете использовать для расширения возможностей своей программы. Во всех своих программах вы включаете заголовки, которые принадлежат стандартной библиотеке, например, iostream , string , vector , array и другие. Обратите внимание, что вам не нужно добавлять в свои проекты iostream.cpp , string.cpp , vector.cpp или array.cpp . Вашей программе нужны объявления из файлов заголовков, чтобы компилятор мог проверить, что вы пишете синтаксически правильные программы. Однако реализации для классов, принадлежащих стандартной библиотеке C++, содержатся в предварительно скомпилированном файле, который подключается на этапе компоновки. Вы никогда не видите кода.
Помимо какого-либо программного обеспечения с открытым исходным кодом (где предоставляются файлы .h и .cpp ), большинство сторонних библиотек предоставляют только файлы заголовков и предварительно скомпилированный файл библиотеки. Для этого есть несколько причин:
- линковка предварительно скомпилированной библиотеки выполняется быстрее, чем перекомпиляция ее каждый раз, когда она вам понадобится;
- одна копия предварительно скомпилированной библиотеки может использоваться несколькими приложениями, тогда как скомпилированный код компилируется в каждый исполняемый файл, который его использует (увеличение размеров файлов);
- соображения интеллектуальной собственности (вы не хотите, чтобы украли ваш код).
Разделение ваших собственных файлов на объявление (заголовок) и реализацию (файл исходного кода) – это не только хорошая организация проекта, но оно также упрощает создание ваших собственных пользовательских библиотек. Создание собственных библиотек выходит за рамки данной серии руководств, но разделение объявления и реализации является предварительным условием для этого.
90 рекомендаций по стилю написания программ на C++
А кому непонятно? Новичкам разве что, но гадлайны, делаются для разработок в компаниях куда не берут людей которые не знают языка. Обычно за
if(ptr != 0) по рукам бьют т.к. это равносильно if(SomeBool == true) конечно компилятор это разрулит, но обычно это заставляет обращать лишнее внимание на условие.
Культурный эффект
- Наследие формата столбчатой карточки с 80 столбцами состоит в том, что отображение 80 символов в строке было обычным выбором при разработке терминалов на основе символов. По состоянию на ноябрь 2011 года некоторые настройки по умолчанию для интерфейса персонажа, такие как ширина окна командной строки в Microsoft Windows, остаются в 80 столбцах, а некоторые форматы файлов, такие как FITS, по-прежнему используют 80-значные изображения карт.
Теперь возникает вопрос: почему IBM выбрала 80 колонок в 1928 году, когда Герман Холлерит ранее использовали 24 и 45 столбцов карты ?
Хотя я не могу найти окончательного ответа, я подозреваю, что выбор был основан на типичном числе символов в строке пишущих машинок того времени.
Большинство исторических пишущих машин Я видел, что ширина валика шириной около 9 дюймов, что соответствует стандартизации размеров бумаги примерно до 8 "-8,5" (см. Почему стандарт размер бумаги в США 8 ½ "x 11"? и История ISO216 Стандарт бумаги ).
Добавьте типичный шаг пишущей машинки 10-12 символов на дюйм, который приведет к документам шириной от 72 до 90 символов в зависимости от размера полей.
Таким образом, 80 символов на строку представляли бы хороший компромисс между шагом отверстия (небольшие прямоугольные и большие круглые отверстия) и длиной линии при сохранении того же размера карты.
Кстати, не везде указывается ширина символа 80 символов в их стандартах кодирования. Там, где я работаю, существует предел в 132 символа, который соответствует ширине типичной строки wide принтеры , а также распечатку формата А4 формата 12pt и типичную ширину линии, оставшуюся в окне редактора Eclipse (максимизированное на экране 1920x1200) после учета обозревателя пакетов и представления схемы.
Тем не менее, я по-прежнему предпочитаю 80-символьный код, так как он упрощает сравнение трех версий файла бок о бок без прокрутки вбок (всегда плохо) или обертывания строк (что разрушает форматирование кода ). При использовании кода шириной 80 символов вам нужен только экран шириной 240 символов (1920 пикселей в 8 пикселей на символ), чтобы увидеть полный
Чтобы более точно и тщательно ответить на вопрос, 80 символов являются текущим «общепринятым» пределом ширины кода внутри редакторов, поскольку форматы 80x24 и 80x25 являются наиболее распространенными режимами экрана на ранних терминалах ввода /вывода и персональных компьютерах ( VT52 - благодаря Sandman4).
Этот предел все еще действителен и имеет какое-то значение IMHO по двум основным причинам: геометрия по умолчанию, которую многие дистрибутивы Linux присваивают вновь созданным терминальным окнам, по-прежнему составляет 80x24, и многие люди используют их as-is , без изменение размера. Более того, ядро, в реальном времени и встроенные программисты часто работают в «безголовой» среде без какого-либо оконного менеджера. Опять же, разрешение экрана по умолчанию часто составляет 80x24 (или 80x25), и в этих ситуациях может быть даже трудно изменить эту настройку по умолчанию.
Итак, если вы являетесь ядром, в реальном времени или встроенным программистом, вы должны заставить себя соблюдать этот предел, просто чтобы быть немного более «дружественным» к любому программисту, который должен читать ваш код.
Хотя, вероятно, не оригинальная причина ограничения 80 символов, причина, по которой она была широко принята, - это просто эргономика чтения :
- Если строки слишком короткие, текст становится трудно читаемым, потому что при чтении вы должны постоянно переходить от одной строки к следующей.
- Если строки слишком длинны, переключение линий становится слишком сложным, потому что вы «теряете линию», возвращаясь к началу следующей строки (это можно смягчить, имея большее межстрочное расстояние, но это также означает пространство).
Это широко известно и принято в типографии. Стандартная рекомендация (для текста в книгах и т. Д.) Заключается в использовании чего-то в области 40-90 символов в строке и в идеале около 60 (см., Например, Википедия , Маркус Итконен: Типография и читаемость ).
Если вы стремитесь к 60 символам в строке, ваш верхний предел, очевидно, должен быть немного выше, чтобы учитывать случайное длинное выражение (и такие, как маркеры полей и номера строк), поэтому наличие верхнего предела 70-80 имеет смысл.
Это, вероятно, объясняет, почему ограничение на 80 символов было принято многими другими системами.
Связанный с этим вопрос: «Почему 80 столбцов сохраняются». Даже ответы на этой странице примерно такова. Я согласен с историческими причинами 80 столбцов, но вопрос в том, почему стандарт сохраняется. Я бы требовал удобочитаемости - для прозы и кода. Наши умы могут поглощать столько информации в одной части. Я все еще использую маркер столбца 80 в своем редакторе кода, чтобы напомнить мне, когда утверждение становится слишком длинным и неясным. Это также оставляет мне много экранной недвижимости для браузера и поддерживающих окон IDE. Да здравствует 80 столбцов - как правило не правило.
Одна из причин заключалась в том, что столбцы 73-80 перфокарты часто резервировались для серийного номера. Почему серийный номер? Если вы уронили карточную колоду, вы можете выбрать карты в любом порядке, выровнять верхние левые углы (которые всегда имели диагональный разрез) и использовать карточную сортировочную машину, чтобы вернуть их в порядок.
Другой причиной 72-символьного ограничения было то, что общие шрифты были на 10 пунктов выше и 6 пунктов (1/12 "). Широкая страница формата A4 или 8.5" могла содержать 72 символа в столбце шириной 6 дюймов и все еще иметь место для полей более дюйма.
Я лично придерживаюсь «около столбца 80» для моего конца строки, потому что дальше это вызывает обертывание или потерянный код при его печати.
Также есть наследие перфокарты, но я не думаю, что лазерные принтеры или бумага размером 8.5x11 дюймов были настроены на соответствие ограничениям перфокарта.
Прокрутка в бумагах принтеров была размером Letter или 15 ".
Это были 80-сантиметровые линейные принтеры для копирования кодов или отчетов, а позже Epson поддерживал сжатую печать 132 сП (escape-код \ 015 для конденсированной печати).
Одна из причин 80 карточек-столбцов может быть связана с «ручным ударом», который, вероятно, использовался перед электронными пусковыми машинами. Это тот, который я использовал в начале 70-х годов на компьютерном сайте ICL System 4-50. Нужно было пробить часть из трех? перфорированные ножи в карете в то же время.
Читайте также: