Форматирование кода программы

[RAlex]

Типогра́фика (от греч. τύπος «отпечаток» + γράφω «пишу») — искусство оформления при помощи наборного (не рисованного) текста, базирующееся на определённых, присущих конкретному языку правилах, посредством набора и вёрстки. Типографика, с одной стороны, представляет собой одну из отраслей графического дизайна, с другой — свод строгих правил, определяющих использование шрифтов в целях создания наиболее понятного для восприятия читателя текста (из Википедии)

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

При работе с IDE PascalABC.NET имеется возможность автоматически отформатировать программный код. С одной стороны, это позволяет выработать единый стиль оформления кода, но с другой ставит жесткие рамки такого оформления. Оформления, которое на мой взгляд, имеет определенные недостатки, в частности, нарушает принципы типографики, направленные на удобство чтения и восприятия текста, что делает строки кода “рыхлыми”.

Принципы типографики гласят, что в тексте нельзя злоупотреблять разрядкой, поскольку взгляд начинает “прыгать” по символам, Мы же видим, что после форматирования нормальная по плотности строка вида

var s:=2*Sin(a[2,3]+1.5*a[0,2]) / (4.28*Pi*Ln(a[2*i,j div 2]));

превращается в

var s := 2 * Sin(a[2, 3] + 1.5 * a[0, 2]) / (4.28 * Pi * Ln(a[2 * i, j div 2]));

Читая любой текст, мы подсознательно воспринимаем его набором фраз, состоящих из слов. А слова отделяются пробелами. Программист в своем коде выделил такие “слова”:

Это выделение позволяло ему четко видеть числитель и знаменатель запрограммированного выражения. Но после форматирования эта строка стала содержать невразумительные “пучки” концентрации символов, разделенные пробелами. Взгляд бежит по ним, спотыкается, разобраться что где намного сложнее. Первая реакция человека, не видевшего такого чудо-форматирования примерно сводится к фразе “Это сейчас что такое было?”. Действительно. что такое “a[0,” ? Какой-то обрывок.

Мы же не обрадуемся, если откроем книгу и она вся будет напечатана фразами, разбитыми на куски подобно “Во тэт о т а к ая фр аза стра нн о на бра н н ая”. Так почему такой стиль должен считаться “правильным” оформлением программного кода?

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

[Sun_Serega]

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

var s :=    2 * Sin(  a[ 2, 3 ] + 1.5 * a[ 0, 2 ]  )    /    (  4.28 * Pi * Ln( a[ 2 * i, j div 2 ] )  );

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

[RAlex]

a[ 2, 3 ]

Это любому покажите обычному человеку - и в ответ будет вопрос, почему не просто a[2,3] ? Когда видим a[2,3] - это ясно, это элемент двумерного массива, я на запись смотрю и вижу имя, дальше квадратная скобка и парная ей - элемент массива, пошли дальше, нужны подробности - задержим взгляд. Когда я читаю a[ 2, 3 ] - мне непонятно, для чего эти индексы окаймлены пробелами, что в них такого важного? Читать даже глазами запись вразрядку дольше. Устает зрение сильнее, если читать такие коды. Найдите хотя бы одну серьезную книгу, в которой в коде были бы отделены пробелом индексы массива от квадратных скобок.

[Gleb]

Ответьте, пожалуйста, на один вопрос. С чего вдруг Вы подняли вопрос с форматированием кода? Там и так не мало ошибок/недоработок, а Вы предлагает сделать форматирование на вкус каждого пользователя.

[Vadim_Dzhenzher]

Так почему такой стиль должен считаться “правильным” оформлением программного кода?

По всей видимости потому, что должен быть какой-то более или менее общий стиль, который поддерживается большим сообществом. Ваш стиль, очевидно, не таков. Хотя к строке с дополнительными пробелами новичку нужно привыкать дня эдак три, Ваша совершенно нечитабельна. Получаетсяпримернотак, аможетихуже. К слову, по правилам набора текста в русской типографской традиции (да и в любой другой тоже) знаки препинания отбиваются справа пробелом. И не надо это путать с набором вразрядку. Проблема форматирования формул в коде несколько надумана, потому что не это самое страшное в плохо отформатированном коде. Страшно, уж извините, Ваше форматирование begin и end , приведённое в начале спора. А также расположение нескольких операторов на одной строке, даже и “логически связанных”.

Многие компании, занимающиеся разработкой софта, вводят свои правила форматирования, в чём-то отличающиеся от общепринятых. Например, гугловые можно легко найти. Это не значит, что все так должны броситься форматировать. А разработчики, на мой взгляд, довели форматирование кода до вполне приемлемого уровня; им можно пользоваться в реальной жизни. Спасибо им за это.

[RAlex]

Я так понимаю, что “общий стиль от большого сообщества” - это форматирование от Visual Studio, удлиняющее строки в 1.5-2 раза? Посмотрим, как складывалось исторически.

Это было вначале, когда стиль написания только начинал вырабатываться.

Потом был Н.Вирт, создавший Паскаль на базе Алгол-60 и Алгол-68.

Потом кто-то решил, что надо понатыкать везде пробелов - где можно и даже, где нельзя. Правда, в литературе по-прежнему этих пробелов особо как бы и нет. Например, тот же Ю.Л. Кетков, полвека писавший книги по вычислительной технике и программированию, упорно не хочет быть “как все” и в своей книге по FPC в 2011 г.пробелы игнорирует:

Конечно же, он не один такой. Вот код из свеженькой IMSL, и если уж и они “плохие” - ну я не знаю тогда…

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

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

[Sun_Serega]

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

[RAlex]

А спорить в каком стиле

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

Я же книгу решил написать, самоучитель по PascalABC.NET. Не хотелось бы там давать примеры кода, форматирование которого все массово будут осуждать.

[Sun_Serega]

Хорошо, не спор. Просто несколько людей написали “а вот мне удобно так” и получили критику друг от друга))) И всё это произошло без какой либо цели, кроме как выразить своё мнение.

[RAlex]

получили критику друг от друга

Не знаю, о ком Вы. Я полагаю, что никого не критиковал, потому что критика - она же в стиле “нет, Вы неправильно/плохо делаете ЭТО”. Персонально к Вам я вовсе не обращался ))) Вы приводили код, да, но он же не Ваш, а получен автоматом.

[Vadim_Dzhenzher]

@RAlex

Я предполагаю, что “ветер дует” от С-подобных языков с их ужасным синтаксисом

Возможно… Просто С-подобных языков больше используют в практике. Что, безусловно, не является причиной копировать оттуда всё подряд в PascalABC.NET.

Касательно пробелов вокруг знаков операций. Мне кажется, что приведённые Вами примеры больше говорят именно о типографских возможностях (или возможностях вёрстки), нежели о стиле кода. Любой из LaTeXовских пакетов для вёрстки листингов делает такие пробелы. Например, что для меня показательнее приведённых Вами скринов, возьмём Кормена:

Я специально так крупно, чтобы было заметнее. Операции и знаки присваивания, в соответствии с TeXовскими рекомендациями, отбиваются пробелами.

Проблема в том, что в коде мы можем вставить только целое неотрицательное число пробелов, и получается, что ноль – мало, а один – много. TeX делает неполный пробел в этих случаях, и всё выглядит более симпатично. Но в текстовом редакторе так не сделать, поэтому приходится округлять: Вы округляете к нулю, а среда – к единице. Я сторонник второго подхода, мне кажется, что он больше соответствует духу TeXа. А Кнут плохому не научит

Про длинные формулы. Раз уж я начал всё про TeX , то приведу (по памяти) ещё одну рекомендацию. Если длинный абзац не может быть хорошо отформатирован TeXом, попробуйте разбить его на два! Это же относится и к длинным формулам. Как-то так.

[RAlex]

попробуйте разбить его на два! Это же относится и к длинным формулам

Вот тут точно с Вами не соглашусь! Разбивать формулу на части - это затруднить понимание кода другим лицом. Можно личный вопрос? Вы много за свою жизнь создали крупных программных комплексов, работая в команде? Если что-то крупное было создано, приходилось ли Вам руководить таким проектом? Его поддержкой при эксплуатации? Если ответ будет отрицательным, тогда Вы и вправду можете считать, что формулы в программе можно разбивать на части “для красоты”.

Кнут плохому не научит

Против микропробелов кто-бы возражал! Но Ваша фраза про стремление к нулю и к единице весьма удачна. Да, я стремлюсь к нулю, мне жаль терять время и портить глаза на ёрзание по строке в поисках парных скобок и т.п. Мне ТАК удобно. Вам - иначе. Ну и отлично, каждый останется при своем мнении)))

[Nolane]

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

[RAlex]

В первом варианте нет системности

Что есть первый вариант? И уж заодно, второй.

[Nolane]

Первый:

var s:=2*Sin(a[2,3]+1.5*a[0,2]) / (4.28*Pi*Ln(a[2*i,j div 2]));

Второй:

var s := 2 * Sin(a[2, 3] + 1.5 * a[0, 2]) / (4.28 * Pi * Ln(a[2 * i, j div 2]));

[Sun_Serega]

Вы приводили код, да, но он же не Ваш, а получен автоматом.

Нет, тот что я выдал я руками отформатировал

никого не критиковал

a[ 2, 3 ]

Это любому покажите обычному человеку - и в ответ будет вопрос, почему не просто a[2,3] ?

Страшно, уж извините, Ваше форматирование begin и end , приведённое в начале спора. А также расположение нескольких операторов на одной строке, даже и “логически связанных”.

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

И не в этой ветке, но по этой же теме

Версия PascalABC.NET 3.4

Begin в конце строчки как стандарт - это ужасно.

Можете говорить что это не критика, объясняя тем что критика это что то более жёсткое. Но это не меняет сути. Несколько человек сказали как им удобно, а потом получили от других “нет, это не удобно”.

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

Ваш был подкреплён тем что “так форматировали несколько десятков лет назад, и ещё есть пара известных уникумов поддерживающих этот стиль”. Насчёт комментариев - ничего кроме “- Мне так удобно; - А мне так не удобно;” я, почему то, не увидел.

Мой был подкреплён личным опытом и был прокомментирован в стиле “Слишком много пробелов. В моём стиле меньше пробелов и мне удобнее когда меньше пробелов”.

Разбивать формулу на части - это затруднить понимание кода другим лицом

Это только непривычка. Мне вот, не раз приходилось разбивать формулу на несколько строчек. И часто не просто друг за другом, а ещё и с пустыми строчками между ними, группируя строчки по смыслу. И это сильно увеличивает читабельность длинных и сложных выражений.

[RAlex]

Понятно. Но Вы противоречите себе же.

Зная формулу программист, не задумываясь, печатает.

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

[Sun_Serega]

Имелось в виду что программист написал, и сразу авто отформатировал.

[Nolane]

Для следования правилам форматирования думать не надо, а для художественного оформления кода “где удобно” нужно постоянно принимать решения.

[RAlex]

ничего кроме “- Мне так удобно; - А мне так не удобно;” я, почему то, не увидел.

Читайте внимательнее и всю ветку - увидите.

Мне вот, не раз приходилось разбивать формулу на несколько строчек.

Тогда и к Вам те же вопросы про создание больших комплексов и работу в команде. Я больше чем уверен, что Вы по стилю работы, как и большинство программистов, одиночка. Т.е. вряд ли Вам приходилось работать в условиях, когда есть большой проект, жесткие сроки, огромная ответственность и постоянная головная боль, когда утром какая-нибудь Валентина не выходит на работу из-за того ,что садик санэпидемстанция закрыла, Николай свалился с гриппом, а послезавтра конец месяца и надо акты выполненных работ получить от оборонного предприятия, где их визируют не только начальник ВЦ, но еще и военпред, а посему надо подключить двоих с другого участка и они в код должны “воткнуться” без заминок. А Валентина - любительница писать задачи, разбивая эти жуткие формулы на кусочки и реализовывать их в своем стиле, единственном и неповторимом…