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

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

надо делать так чтобы было читаемо. если код редактируют в консоли, то надо делать 80, если не в консоли, то 120, 150 и так далее пока станет нечитаемо. если кто-то требует 80, но никто не редактирует в терминале - надо лупить тряпкой по морде и отправлять работать. от языка не зависит.

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

Читаешь строку, если дочитал до конца и забыл, что в начале, то лучше так не делать.
Т.к. флот плывет со скоростью самого медленного буксира, то включайте сюда ноутбуки, которые редко >17", а в мелкобукву не всякий любит и может, то 80-100 примерно и есть нормальная длина для кода.
Для маленького эссе про этот код или того, кто раньше его писал тоже удобнее разбивать на небольшие куски с абзацами, т.к. удобнее сверху за вниз, а не слева - на право до горизонта.

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

В общем на full hd на 23 дюймовом мониторе для комфортной работы мне шрифт 16-17 нужен не менее. Даже в очках. Соответственно, 80 может все-равно устарели, но и больше 100-110 неудобно

Используем нормальные мониторы

Вот это ты крут. Я то 4K@27" использую. Не покажешь на своем нормальном мониторе два столбца текста и сайдбар рядом?

ну насчёт тебя никаких сомнений и не было. вообще двойное окно используется всегда когда просматривается дифф перед комитом, что какбы намекает, что альтернативно одарённые люди 1) этого не делают 2) не умеют пользоваться своими инструментами и не знают хоткей для скрытия сайдбара 3) найдут причину полезть в зал*пу даже если перед ними поставят 27" телевизор.

Я сначала крутил у виска, глядя то на 32" монитор, то на это ограничение на текущей работе, но со временем понял, что это довольно-таки удобно. Во-первых, можно горизонтально разбить редактор на несколько частей и держать по три открытых файла во всю высоту экрана. Во-вторых, по той же причине намного удобнее делать код ревью с side-by-side diff даже на лаптопе. В-третьих, это не дает делать код тошнотворно нечитаемым: если какой-то тип становится слишком длинным, то имеет смысл ввести алиас; если какая-то конструкция становится слишком монструозной, то имеет смысл вынести ее части в отдельную функцию; и так далее. Пишу преимущественно на C++ и Python.

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

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

как обычно всё зависит от людей которые работали над кодом, главное чтобы тебе самому нравилось.

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

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

Все аутисткие антипаттерны пресекаются во время ревью

сомневаюсь что все, 80 - это объективно мало. комментарий в ту же строку часто не влезет, а выносить в другую может быть неудобно, из-за того же ограничения он будет не на своём месте. поэтому человек может предпочесть не писать комментарий вместо того чтобы создавать повод для конфликта во время ревью. ну и те кто реально видел то что получается из форматирования в 80 символов на практике, врядли поверят в «качество кода сильно выше среднего», скорее определение «среднего» слегка занижено.

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

Угу. Попробуй в ядро закоммить код, не соответствующий этому дохлому и неиспользуемому стандарту.

The Linux Kernel Deprecates The 80 Character Line Coding Style

Я буквально вчера в рабочем проекте видел строку в 295 символов, и ещё 71 символов перенесено на другую строку. Я даже себе сохранил. Такого я ещё не видел. Та самая строка на JS:

b_edited = default_data && $.trim(default_data['contents'][lang_id].replace(/ /g, ' ').replace(/\s/g, '')) != $.trim(data['contents'][lang_id].replace(/ /g, ' ').replace(/\s/g, '')) && $('[id*=article_lang_' + lang_id + ']').find('.js_omni_redactor_container').text().trim().length > 0
&& Object.keys(data['contents'][lang_id]).length > 0 ? true : b_edited; 

комментарий в ту же строку часто не влезет

Взял да перенес. Аутисткие заморочки это как раз-таки про то, что одно слово свисает или правый край менее выровненным получается.

а выносить в другую может быть неудобно

Примеры?

скорее определение «среднего» слегка занижено

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

Взял да перенес.

А вот и первый типично-аутистский подход из-за ограничения 80 символов, создающий говнокод.

Цитируем Torvalds’а:

Excessive line breaks are BAD. They cause real and every-day problems.

They cause problems for things like «grep» both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based.

Longer lines are fundamentally useful. My monitor is not only a lot wider than it is tall, my fonts are universally narrower than they are tall. Long lines are natural.

People with restrictive hardware shouldn’t make it more inconvenient for people who have better resources. Yes, we’ll accommodate things to within reasonable limits. But no, 80-column terminals in 2020 isn’t «reasonable» any more as far as I’m concerned. People commonly used 132-column terminals even back in the 80’s, for chrissake, don’t try to make 80 columns some immovable standard.

If you choose to use a 80-column terminal, you can live with the line wrapping. It’s just that simple.

And longer lines are simply useful. Part of that is that we aren’t programming in the 80’s any more, and our source code is fundamentally wider as a result.

На экран помещается как раз 140. Живу с 80 и разбиваю емакс на два. Диффы читаю. Пишу с телефона. Стодвадцатников с синдромом arrow antipattern не уважаю.

My monitor

Вот и всё оправдание.

My laptop does not support optical media nor Ethernet anymore, let’s deprecate that.

our laptops do not support erasing the firmware so let’s mount it read-write

Цитируем Torvalds’а

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

ну так подобные ограничения обычно и бывают там где «слово свисает» или «край не выровнен». здоровому человеку какая разница, 80 там символов или 82.

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

Примеры?

const int some_shit = anal::function(variable1, variable2, magic(variable3), 
                                     variable4);

напоминает ваш код? ну попробуй написать комментарий к magic(variable3).

вполне можно перенести.

и комментарии не нужны, это говнокод.

если нужны комментарии, то создавай временную переменную с именем вместо комментария.

using anal::function;
auto&& const description = magic(variable3);
int const some_shit = 
  function(variable1, variable2, description, variable4);

На экран помещается как раз 140. Живу с 80 и разбиваю емакс на два.

но 80 * 2 = 160, анон-кун.

They cause problems for things like «grep»

Использовать

--context

это говнокод.

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

using anal::function;

это тоже говнокод.

auto&& const description = magic(variable3);

ещё говнокода привалило.

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

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

Так и получается у меня меньше, чем 80. 70 где-то. И если добив до 80, у меня появится небольшой хвостик, то при 120 хвостик занимает практически две строки.

ты не понял в чём говнокод и почему челик написал auto&&. а он понял и написал именно так, но получился говнокод.

но вообще, если делают макаки, то любой кодинг стайл лучше чем никакого кодинг стайла, вот прямо любой. так что пойдёт.

Пишу и собираюсь показывать. На питоне. Pep8 с его 79 символами идёт тут в пень, потому что я жабой болел и длинные названия ко мне прилипли, т.е. название аргумента вида user_api_key вполне нормальны, как и глубокая вложенность, а ещё я и аннотацией типа со значением по умолчанию не стесняюсь их мазать. Так что жуём 120 символов, а что поделать? Объявление функции на 4 строки писать это совсем посос.

Почему никто не написал про ide-ориентированные языки и манеры накидательства кода в IDE?

и аннотацией типа

А вот и свидетель IDE вылез.

Вы разбиение экрана (несколько окон рядом)

Нет. Alt-Tab и виртуальные рабочие столы - наше всё.

Да. Там и && и const. Но const нельзя move делать… Аноним прав, с auto там косяк.

Вот с using я не понял, почему ему не нравится так избавляться от префикса namespace.

КЕК

80 символов хватит всем

Если в Питоне тебе мало 80 символов на строку, то ты делаешь что-то не так.

это засоряет пространство имён ради экономии 6 символов и создаёт потенциальный конфликт имён с глобальным function который не диагностируется. это было бы оправданно если бы неймспейс был бы очень длинным, но в этом случае без using было бы лучше, и вообще без using практически всегда лучше.

Python в vim-е уж больно противный, после Pycharm. Ты ещё и про C# в чём-то отличном от VisualStudio и юзабельность этого расскажи мне. Это сишку с крестами можно в чём угодно жрать, для них так и не сделали нормальных IDE. Можно ещё вынуждено каку жевать, когда проект слишком велик и IDE от него плохо. А мазохизм ради мазохизма ну так себе идея. Мне задачу надо решать, а не с окружением сексом заниматься.

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

А вы говорили, емаксовимеры — фашисты, заставляют все жить, как они. Вот он, настоящий облик IDE-тирана.

Ага, например пытаешься писать на нём что-то юзабельное. Вот тебе из pandas-а примеры лапши в 80 симмволов:

    @Substitution(**_shared_doc_kwargs)
    @Appender(NDFrame.sort_values.__doc__)
    def sort_values(
        self,
        by,
        axis=0,
        ascending=True,
        inplace=False,
        kind="quicksort",
        na_position="last",
        ignore_index=False,
    ):
        inplace = validate_bool_kwarg(inplace, "inplace")
        axis = self._get_axis_number(axis)

        if not isinstance(by, list):
            by = [by]
        if is_sequence(ascending) and len(by) != len(ascending):
            raise ValueError(
                f"Length of ascending ({len(ascending)}) != length of by ({len(by)})"
            )
        if len(by) > 1:
            from pandas.core.sorting import lexsort_indexer

            keys = [self._get_label_or_level_values(x, axis=axis) for x in by]
            indexer = lexsort_indexer(keys, orders=ascending, na_position=na_position)
            indexer = ensure_platform_int(indexer)
        else:
            from pandas.core.sorting import nargsort

            by = by[0]
            k = self._get_label_or_level_values(by, axis=axis)

            if isinstance(ascending, (tuple, list)):
                ascending = ascending[0]

            indexer = nargsort(
                k, kind=kind, ascending=ascending, na_position=na_position
            )

        new_data = self._data.take(
            indexer, axis=self._get_block_manager_axis(axis), verify=False
        )

        if ignore_index:
            new_data.axes[1] = ibase.default_index(len(indexer))

        if inplace:
            return self._update_inplace(new_data)
        else:
            return self._constructor(new_data).__finalize__(self)

ЗЫ

Что такое na_position я в душе не понимаю. Надо задумываться. Возоможно русский писал и это начальная позиция, но блин, это говнокод форменный.

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

Эти оба парня давно уволены, ты о чём?

примеры лапши в 80 симмволов

Кто запретил аргументы писать не по одному, а в строчку по мере наполняемости?

Кому понадобилось вычислять len от двух аргументов по два-три раза?

Кто делает импорты внутри функций?

Это говнокод, но говнокод это явно не из-за 80 строк.

За

inplace = validate_bool_kwarg(inplace, «inplace»)

отдельный кек. Родина дала декораторы, пользуйся, нет, не хочу, хочу жрать навоз!

Но между тем это не мой говнокод, это говнокод из pandas-а, который типа промышленное решение и стандарт де-факто для работы с csv и электронными таблицами в Python-е. Лучшей альтернативы просто нету.

Ну и да, там так может быть что его ускоряли сильно, потому что нагрузка на него бешеная идёт.

его ускоряли сильно

Из десяти len() сделали 3?

Это я к вопросу об импортах, хотя len-ы больше профита бы дали.

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

А за кодинг на мобильниках ide-профсоюз будет устраивать засады за гаражами.

Как все течет, все изменяется. Из похожих тем внизу в 2008 году 80 символов (комментарий)

Rastafarra писал тогда

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

Интересно сейчас так же думаешь?

В основном код, написанный коллегами читается через узенькие колонки в интерфейсе gitlab или github. При редактировании же обычно надо исправлять несколько мест сразу, так что вертикальные сплиты открыты почти всегда. В обоих случаях портяны, написанные в ширину, ясное дело вообще не читаются, так что софт-лимит на 80 никуда не исчез и не собирается. Софт-лимит - потому что 1) не все языки и инструменты умеют нормально переносить строки и 2) когда переносы существенно ухудшают читабельность, например длинные URL в YAML лучше оставить как есть.

нет, не хочу, хочу жрать навоз!

так это же бидон, в нём бай дезигон так

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

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