Возможно… Просто С-подобных языков больше используют в практике. Что, безусловно, не является причиной копировать оттуда всё подряд в PascalABC.NET.
Касательно пробелов вокруг знаков операций. Мне кажется, что приведённые Вами примеры больше говорят именно о типографских возможностях (или возможностях вёрстки), нежели о стиле кода. Любой из LaTeXовских пакетов для вёрстки листингов делает такие пробелы. Например, что для меня показательнее приведённых Вами скринов, возьмём Кормена:
Я специально так крупно, чтобы было заметнее. Операции и знаки присваивания, в соответствии с TeXовскими рекомендациями, отбиваются пробелами.
Проблема в том, что в коде мы можем вставить только целое неотрицательное число пробелов, и получается, что ноль – мало, а один – много. TeX делает неполный пробел в этих случаях, и всё выглядит более симпатично. Но в текстовом редакторе так не сделать, поэтому приходится округлять: Вы округляете к нулю, а среда – к единице. Я сторонник второго подхода, мне кажется, что он больше соответствует духу TeXа. А Кнут плохому не научит
Про длинные формулы. Раз уж я начал всё про TeX , то приведу (по памяти) ещё одну рекомендацию. Если длинный абзац не может быть хорошо отформатирован TeXом, попробуйте разбить его на два! Это же относится и к длинным формулам. Как-то так.
Вот тут точно с Вами не соглашусь! Разбивать формулу на части - это затруднить понимание кода другим лицом. Можно личный вопрос? Вы много за свою жизнь создали крупных программных комплексов, работая в команде? Если что-то крупное было создано, приходилось ли Вам руководить таким проектом? Его поддержкой при эксплуатации? Если ответ будет отрицательным, тогда Вы и вправду можете считать, что формулы в программе можно разбивать на части “для красоты”.
Против микропробелов кто-бы возражал! Но Ваша фраза про стремление к нулю и к единице весьма удачна. Да, я стремлюсь к нулю, мне жаль терять время и портить глаза на ёрзание по строке в поисках парных скобок и т.п. Мне ТАК удобно. Вам - иначе. Ну и отлично, каждый останется при своем мнении)))
В первом варианте нет системности. Вот вам кажется, что так красивее или читается легче, а кому-то наоборот. Как мне или другому программисту решить где ставить пробелы, а где нет?
Во втором варианте постановка пробелов подчиняется некоторому набору правил. Зная формулу программист, не задумываясь, печатает. Ему не надо решать такой сложный вопрос как форматирование кода.
Можете говорить что это не критика, объясняя тем что критика это что то более жёсткое. Но это не меняет сути. Несколько человек сказали как им удобно, а потом получили от других “нет, это не удобно”.
Но, что важнее - сейчас у этой ветки нету никакой чёткой и достижимой цели.
Вы писали, в начале, что это всё чтоб разработчики узнали как правильнее может работать форматирование. Пример, как может быть лучше, приводили только вы и я.
Ваш был подкреплён тем что “так форматировали несколько десятков лет назад, и ещё есть пара известных уникумов поддерживающих этот стиль”. Насчёт комментариев - ничего кроме “- Мне так удобно; - А мне так не удобно;” я, почему то, не увидел.
Мой был подкреплён личным опытом и был прокомментирован в стиле “Слишком много пробелов. В моём стиле меньше пробелов и мне удобнее когда меньше пробелов”.
Это только непривычка. Мне вот, не раз приходилось разбивать формулу на несколько строчек. И часто не просто друг за другом, а ещё и с пустыми строчками между ними, группируя строчки по смыслу. И это сильно увеличивает читабельность длинных и сложных выражений.
Вот когда не задумываясь печатает формулу и ставит пробелы лишь там, где ему самому удобно, чтобы не ошибиться лишний раз - это как раз первый вариант. А второй - это то, что из первого делает программа форматирования, его не надо набирать в таком виде, это обезьянья работа - втыкать везде пробелы руками. Речь о том, нужны ли они вообще.
Тогда и к Вам те же вопросы про создание больших комплексов и работу в команде. Я больше чем уверен, что Вы по стилю работы, как и большинство программистов, одиночка. Т.е. вряд ли Вам приходилось работать в условиях, когда есть большой проект, жесткие сроки, огромная ответственность и постоянная головная боль, когда утром какая-нибудь Валентина не выходит на работу из-за того ,что садик санэпидемстанция закрыла, Николай свалился с гриппом, а послезавтра конец месяца и надо акты выполненных работ получить от оборонного предприятия, где их визируют не только начальник ВЦ, но еще и военпред, а посему надо подключить двоих с другого участка и они в код должны “воткнуться” без заминок. А Валентина - любительница писать задачи, разбивая эти жуткие формулы на кусочки и реализовывать их в своем стиле, единственном и неповторимом…
Читая любой текст, мы подсознательно воспринимаем его набором фраз, состоящих из слов. А слова отделяются пробелами. Программист в своем коде выделил такие “слова”:
Это выделение позволяло ему четко видеть числитель и знаменатель запрограммированного выражения. Но после форматирования эта строка стала содержать невразумительные “пучки” концентрации символов, разделенные пробелами. Взгляд бежит по ним, спотыкается, разобраться что где намного сложнее.
Да, вовсе не обязательно я. Например, начинающий изучать программирование. Первое время очень многие испытывают проблемы даже правильно расставить скобки. Я встречал коды, где люди ставили дополнительные пары скобок не полагаясь на приоритет выполнения операций… да много разного встречал. И потом, это пробел “рабочего периода”, после проверки работоспособности кода, он не нужен.
, то приведу (по памяти) ещё одну рекомендацию. Если длинный абзац не может быть хорошо отформатирован TeXом, попробуйте разбить его на два! Это же относится и к длинным формулам. Как-то так.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021