А оно потому и художественное. Вы определитесь уж - или Вы кодировщик-ремесленник, или художник от программирования!
По делу есть что сказать?
Если для Вас это не по делу, то давайте на этом и закончим.
Давайте
Прочитал, несколько раз. Может вы мне покажете какой ответ не подходил под этот шаблон?)))
Да самое первое сообщение в ветке (ТС) - оно ничего не содержит в стиле “ЛИЧНО МНЕ так неудобно”.
Читая любой текст, мы подсознательно воспринимаем его набором фраз, состоящих из слов. А слова отделяются пробелами. Программист в своем коде выделил такие “слова”:
Это выделение позволяло ему четко видеть числитель и знаменатель запрограммированного выражения. Но после форматирования эта строка стала содержать невразумительные “пучки” концентрации символов, разделенные пробелами. Взгляд бежит по ним, спотыкается, разобраться что где намного сложнее.
Этот программист, конечно же, не лично вы.
Да, вовсе не обязательно я. Например, начинающий изучать программирование. Первое время очень многие испытывают проблемы даже правильно расставить скобки. Я встречал коды, где люди ставили дополнительные пары скобок не полагаясь на приоритет выполнения операций… да много разного встречал. И потом, это пробел “рабочего периода”, после проверки работоспособности кода, он не нужен.
Программист считает, что вы выдаёте своё мнение за общепринятое.
1 лайк
Программист считает ошибочно. Скорее даже предвзято. Но это останется на его совести.
Есть современные тенденции форматирования. Одна из хороших книг -
С.Макконнелл. Совершенный код. http://readingbook.ru/computer-technology/351-sovershennyy-kod-master-klass.html
Форматированию посвящена глава 31.
Форматирование Вирта было давно когда все данные набивались на перфокартах, и мы впихивали на одну строчку как можно больше, экономя перфокарты.
Кроме того, не надо забывать, что многие дебаггеры выполняют программу построково - наш в частности.
Поэтому - одна строка - один оператор.
2 лайка
Можно. Хотя это не может расцениваться ни как подтверждение, ни как опровержение моего мнения. В середине 90-ых, обучаясь в аспирантуре, я участвовал в создании комплекса программ моделирования молекулярных спектров LEV. Главным образом разрабатывал расчёт электронно-колебательных спектров молекул. Комплекс писался на Фортране, которого я тогда совершенно не знал. Пришлось вливаться в команду. Требований к оформлению кода как таковых не было. Это, плюс особенности Фортрана как языка, навсегда приучило меня к важности форматирования. Сейчас пытаюсь (порой безуспешно) привить культуру оформления кода студентам.
Тут ведь не в красоте дело. Я про неё и не упоминал вовсе, так что непонятно, зачем кавычки. В физике очень часто можно выделить часть сложной формулы. То есть эта часть будет иметь физический смысл. Если это так, то никакого вреда, кроме пользы, нет в том, чтобы завести для этой части отдельную переменную и использовать её впоследствии. Глядишь, и ещё где-то пригодится. Вообще, форматирование не про красоту, оно про читабельность. А красота – это свойство идеи 
В заключение хочу ещё раз подчеркнуть: форматирование формул – это лишь один и, на мой взгляд, не самый важный аспект форматирования кода. Гораздо больше вреда наносят несоотнесённые вертикально операторные скобки, написание программы в одну строчку (как её потом отлаживать?), написание программ вообще без отступов (а я потом всё сразу отформатирую… Ага…), дурацкие имена переменных и подпрограмм и пр.
Каждый, разумеется, останется при своём мнении. Любое форматирование лучше отсутствия такового. Но пусть в коде отражается не только наше представление о прекрасном, но и структура алгоритма. Тогда его поймут все.
2 лайка
Как раз это меня раздражает больше всего в автоформатировании. Потом очень долго руками эти пробелы лишние убирать.
По поводу прочего - спасибо, буду думать, что из этих рекомендаций стоит взять на вооружение. Поскольку они все же рекомендации, а не догма.
Ну так авто форматирование их не делает ведь. Именно в этих местах.
К сожалению, в упомянутом источнике нет упоминаний о том, как расставлять пробелы в выражениях, разделяя операции и операнды. Посему и пришлось показать именно этот пример, а не другой. Но имелась в виду не буква, а дух.
Наверное, слегка оффтоп, но…
Гхм, а что в этом плохого? Постоянно так делаю. Когда перед тобой стоит задача уровня “написать высокоуровневую логику работы бизнес-приложения”, думаешь о ней, а не вспоминаешь, что там впереди - логические операции, арифметика, тернарные операторы, указатели/ссылки, или какая иная чушь. Ради того, чтобы сэкономить четыре-шесть символов кода придется потратить пару минут, чтобы перепроверить, и убедиться, что выражение написано верно. Будет выглядеть слегка красивее. Но стоит ли оно того? Появится баг в системе, и каждый раз эта строка (даже десять раз проверенная), будет обращать на себя внимание - непроизвольно будешь думать, что в написании совершил ошибку. А доводить эти элементы ЯП (тем более, что в разных ЯП оно работает по разному - сравните a == b == c в python и С++, к примеру) до автоматизма - ну… не то, чтобы нельзя, но имеет мало смысла. Не так уж часто мы этим пользуемся, чтобы скобки экономить.
Если что-то с этим пробелом читается лучше (т.к. именно ради этого его там поставили в “рабочем” периоде), значит, его там нужно оставить. Главная задача большинства программистов, вопреки мнению, тут присутствующему, не написать кучу своего кода фана ради, а разобраться в том, что там до тебя понаписали, и как через эти колеса просунуть палку так, чтоб велосипед с коленками остались целыми…
+1
1 лайк
Нету, но там везде расставляются все пробелы. Справа и слева от каждого :=, +, -, *, /, <, > и т.п.
И что из этого следует? Ну, расставили там пробелы, дальше что? Мое личное мнение - хороши полиграфические пробелы при отбивке операций в типографском издании текста программы (что отметил @Vadim_Dzhenzher), а в обычном написании это головная боль. По совокупному мнению авторов обоих работ, ссылки на которые привел @Admin, длина строки программы не может превышать 80 символов, что регулируется разбиением длинных строк. Пишем оператор, потом вставка этих “бешеных пробелов” при автоформатировании делает часть строк программы длиной более 80 символов и надо это отслеживать, вручную разбивая строки? Нет уж, пусть этим занимаются энтузиасты-перфекционисты. Напомню еще раз, что стандарта на оформление текстов программ нет и все это не более, чем частное мнение тех или иных групп людей. Каждый должен для себя сам решить, как оформлять программу с тем, чтобы она имела наиболее подходящий для отображения алгоритма, а также удобный для восприятия и работы над текстом вид.
Можно ставить пробелы сразу.
1 лайк
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021