LINUX.ORG.RU

2020: 80 символов на строку кода

 


0

1

ЛОРчане(-чанки), как думаете, имеет ли смысл сегодня придерживаться ограничения длины строки кода 80-ю символами?
Если нет то какое ограничение лучше ставить по вашему мнению?

UPD:
Пишите язык для которого даёте рекомендацию по размеру строки, например, в Си 80 нормально, а в Питоне мало.

★★

Последнее исправление: MaxPower (всего исправлений: 1)

Ответ на: комментарий от praseodim

а мало что поменялось на самом деле.

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

Rastafarra ★★★★
()
Ответ на: комментарий от anonymous

в нём

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

Тем не менее: раньше язычок пилился людьми, которые не осиливали перл, из чего вылезали ограничения и карнавал в виде one way to do it. Сейчас эти самые люди слегонца научились в more than one way to do it и теперь у нас вместо питона просто убогая версия перла. По аналогии, раньше эти люди кодили на ноутбуках, а теперь ядро сообщества сидит на 4k мониках и попивает смузи, тыкая в IDE, поэтому лимит на символы повысили.

anonymous
()

Язык значения не имеет. Side-by-side diff портится всюду одинаково. Пример. При ограничении в 80 символов такой фигни не будет, даже не надо на всю ширину экрана разворачивать и ещё место останется для номеров строк и всего такого. Да, иногда можно располагать одно под другим, но это существенно менее удобно читать и может требовать очень частой прокрутки.

xaizek ★★★★★
()

Нужны ограничения на длину имён функций/переменных и на количество вложенных конструкций.

Если для строки сырца недостаточно 80 символов - значит что-то сделано очень неправильно. Никогда не понимал, что может заставить человека обозвать какую-нибудь переменную цикла indexOfSomeArrayElement, вместо того, чтобы использовать и переиспользовать классические i,j,k… Если об использовании goto/return и т.п. для уменьшения вложенности и всего такого ещё можно поспорить, то это вообще ни в какие ворота не лезет.

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

Stanson ★★★★★
()
Ответ на: комментарий от Rastafarra

Я не спорю, хотя иногда 80 символов бывает маловато. И не для колбасни или длиннющих имен, а вполне по делу.

praseodim ★★★★★
()

ЛОРчане(-чанки), как думаете, имеет ли смысл сегодня придерживаться ограничения длины строки кода 80-ю символами?

Нет конечно. Или ты ограничиваешься, потому что диды ограничивались?

K56
()

а что, кроме ифов и строк, у тебя сильно и часто за 80 выпирает?

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

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

rukez ★★★★
()

Предпочитаю нестрогие рамки, т.е. ориентир на 120, редактор на 130-135 + гуттер (132 если князь олдфагов), но если с гулькин нос переносится, то можно и оставить. А если даже меньше 120, но некрасиво, то можно и силом перенести. Все зависит от перспективы и композиции, а не от сухих технических заскоков.

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

anonymous
()

Вы не задумывались почему с бумажных газетах пишут колонками? Ведь могли бы и во всю ширину

anonymous
()
Ответ на: комментарий от anonymous

Потому что так код удобнее читается конечно же, почему ещё?

int usage(void);      } else if (argc == 1)    }
                          {                  }
int main(int argc,      printf("Hello,
    char *argv) {     a n o n y m o u s " )
  if (argc < 1) {         ;
    return usage();     return 0;

anonymous
()
Ответ на: комментарий от anonymous

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

к 80 символам относится синтаксис на отступах

людьми, которые не осиливали перл

а зачем осиливать перл? чтобы превозмогать?

и теперь у нас вместо питона просто убогая версия перла

потому что надо было просто брать какую-нибудь scheme и не выпендриваться

anonymous
()
Ответ на: комментарий от anonymous

Смотря что и смотря как. Бигдату ту вообще кодить и тестировать на разных железках надо. Но так да, 16 гигов это минимально комфортный уровень из-за жаба IDE.

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

Потому что мысли коротенькие. Абзац в строку не влезет, точнее влезет, но пустого места больше будет.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)

С распространением широких мониторов можно использовать 100-120, но обычно не нужно. Если строка вылезает за 80 символов, то это скорее маркер что «что-то тут не то» или с форматированием или с неймингом или с вложенностью.

Касается любого языка, тащем, хоть лиспа, хоть си, хоть жавы.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anonymous

а зачем осиливать перл? чтобы превозмогать?

Затем, что перл у нас то, от чего убегали не осилившие перл питонцы. Перл же у нас, как ты и заметил, сделан неосиляторами лиспа, о чём признался Ларри, говоря, что lisp did not cater to mere mortals.

потому что надо было просто брать какую-нибудь scheme и не выпендриваться

В конце концов это так, судя по циклу развития сегодняшней скриптоты. Ждём непитон и продолжение круговорота.

anonymous
()

80 много, надо 70.

Тех, кто пишет код во всю ширину широкоформатного монитора - гнать из профессии.

Если ты программист, поступи правильно, поверни монитор вертикально.

yoghurt ★★★★★
()
Ответ на: комментарий от rupert

Коль начал рыть, смотри и остальные ПРы тогда :) центр масс все равно в районе 40й колонки.

yoghurt ★★★★★
()
Ответ на: комментарий от rupert

Ну и да, ты думаешь я от этого не страдаю? Ещё как страдаю.

yoghurt ★★★★★
()

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

а если какое-нибудь echo-сообщение не влезает в строку, то пофигу, никогда специально не переношу вывод чего-либо.

Spoofing ★★★★★
()
Ответ на: комментарий от Result-Code

80 для C, 120 для C++

«Прогресс» удобства очевиден.

anonymous
()
Ответ на: комментарий от Spoofing

а если какое-нибудь echo-сообщение не влезает в строку, то пофигу, никогда специально не переношу вывод чего-либо.

Теперь понятно почему (ба)ш-лапша любить выводить на экран ‘цитаты из «Войны и мира»’.

anonymous
()
Ответ на: комментарий от grem

Я ж не ретроград.

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

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Да, я молодец!

Насчёт строчек без переносов я не шучу. Я знаю такого человека.

grem ★★★★★
()
Ответ на: комментарий от anonymous

80 это натуральный карго-культ. Все уже забыли почему и зачем, тыкают в древние уставы: вот написано 80 бубубу, диды мол знали толк

Диды действительно знали толк, и всё достаточно легко объясняется.

Хорошо написанный код слабо отличается от хорошо сверстанной книги, а верстка хорошей книги - это грамотная ширина печатной строки для удобного потребления глазом. См. например, почему LaTeX по-умолчанию форматирует article именно так как он это делает.

yoghurt ★★★★★
()
Ответ на: комментарий от anonymous

Все зависит от перспективы и композиции

горизонт завален !!! 111

anonymous
()

имеет ли смысл сегодня придерживаться ограничения длины строки кода 80-ю символами?

Эту херню придумали во времена ФОРТРАНа, потому что на перфокарту входит только 80 символов. Сам-то как думаешь, это ещё актуально, или уже можно расслабить булки?

no-such-file ★★★★★
()

А какой смысл в этом ограничении? При нынешних мониторах и кол-ве знаков в видимой области?

anonymous
()
Ответ на: комментарий от anonymous

Тут скорее вопрос форматирования. Но это не ограничение в 80 знаков, а удобство чтения блоков кода.

anonymous
()

Имеет смысл ограничивать количеством «слов» – человекам будет проще наводиться. Длинна слов зависит, и ширина букв может, т.ч. в буквах цифра не универсальна. И, уже говорили, имеет смысл укладываться в 1/3, или хотя бы 1/2, ширины экрана, для мержей, подсказок, и всякого интерфейса, кто не может без этого.

Для примера, мой телевизор и шрифт как раз даёт 80 по второму критерию, т.ч. как бы не о чем спорить. Если 3 файла не мержить, можно 120.

DonkeyHot ★★★★★
()

PS

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

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: PS от DonkeyHot

Я об этом говорил ещё в 2018, 2017, 2015, 2013 и 2011 годах, но никто не прислушался.

anonymous
()
Ответ на: комментарий от anonymous

никто не прислушался

Наверное, ты это тоже людям говорил. Может нужно было компилятору?

DonkeyHot ★★★★★
()

У меня как-то так:

  • Python — почти строго 80
  • Bash — 80, иногда 100 в зависимости от скрипта
  • Си — 120
  • JS — 120
  • Java — без ограничений
  • HTML — без ограничений
  • CSS — строго 80
anonymous
()

Що, опять?!

Не надоело ещё?

mord0d ★★★★★
()
Ответ на: PS от DonkeyHot

лисп

anonymous
()
Ответ на: комментарий от CryNet

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

thunar ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.