[Oberon-07] Руководство по стилю кодирования

[Илья Ермаков]

Пропорциональные шрифты, похоже, используют лишь блекбоксёры и ненавидимый ими Страуструп )))

Страуструп - неглупый мужик. В частности, его понимание необходимости и особенностей "универсального императивного языка уровня 3GL" совершенно отлично сформулировано (привет функциональщикам).
Если учесть также его признание, что "аналог С++ можно бы сделать в 10 раз компактнее", то ещё интереснее.

Мешало всегда желание доминирования в среде сишников за счёт охвата обычного С - и предрассудок "нельзя навязывать программисту только один способ что-то сделать, надо давать выбор". Короче, странный аргумент, что каждый пользователь языка имеет право сойти с ума своим неповторимым образом.
Эти два заблуждения Страуструпа, уверен, сознательные, т.к. человек поставил своей целью сделать мега-популярный язык. И только во вторую очередь ещё и язык, каким-то объективным требованиям соответствующий.

[valexey_u]

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

Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??

Не знаю как блокнот, а я вот сам плачевно реагирую на табуляцию :-)

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

[valexey_u]

так что разумное использование выравнивания очень приветствуется.

Лучше пишите так:

TYPE
  Event = RECORD
    date    : Date;
    time    : Time;
    location: Location
  END;

Угу, и если нужно добавить новое поле, то я буду перебивать отступы в 5 соседних? Удивительно, как часто забывается, что "программёр больше не писатель, а менятель".
Специальный редактор/плагин будем искать для такого? Особенно, после того, как отказались от табуляций, потому что хотим работать в гипотетических "любых редакторах"...
"Разумное использование выравнивания приветствуется..." - так разумное или чрезмерное? Что добавляет для читабельности вот это центрование двоеточий?
Вот будет семантическое редактирование - и табличка объявлений в таком редакторе, это дело. А изголяться так в тексте...

Предлагаю говорить о вкусе устриц с теми, кто их ел (а не пробовал) :-)

Я на работе именно так оформляю код на Objective-C (и не только я - это распространенная практика). В результате во-первых код выглядит эстетичней и читается легче, а во-вторых обозначенных проблем я не наблюдаю. То есть да, иногда добавляешь поле и нужно что-то там подравнять, ну дык это не проблема вовсе. В любом случае код читается много чаще чем редактируется.

Разумное выравнивание - это означает что если у нас подряд идет вначале 2 поля в 2 буквы, а затем 3 поля с длиной названия в 20 букв, то, видимо, не стоит их выравнивать одинаково.

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

[valexey_u]

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

Лучше бы пропагандировать ограничение размера процедур в среднем 15 строками и запрещать вложенность циклов в рамках одной процедуры (кроме случаев типа FOR x .... DO FOR y... DO FOR z ... DO...).
И тогда логически "связанные блоки программы" будут оформлены, как и следует, отдельными процедурами.

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

[valexey_u]

Не знаю, как это реализовывать в плоском тексте...

Но я использую оформление подчёркиванием выходных параметров при вызове процедур:

GetXxxXxx(aa, bb, cc, cc)

А для var-аргументов? OUT-параметров в Обероне нет.

[Илья Ермаков]

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

Полностью согласен. Но для алгоритмоёмкого кода моё правило как раз применимо на 100%. Оно соответствует и ходу проектирования алгоритма пошаговой детализацией. (Кстати, именно такую культуру в своих учебниках настойчиво, с первых занятий, прививает Кушниренко - в школьном и в мехматовском вузовском).

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

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

[Илья Ермаков]

А для var-аргументов? OUT-параметров в Обероне нет.

То же самое... Подчёркиваем эффект изменения переменной, а уж входно-выходное оно или просто выходное - вторично.

[valexey_u]

А для var-аргументов? OUT-параметров в Обероне нет.

То же самое... Подчёркиваем эффект изменения переменной, а уж входно-выходное оно или просто выходное - вторично.

VAR-параметры это да, проблема... Причем по хорошему, эта проблема должна бы решаться на уровне языка.

В этом плане мне даже больше нравится Си чем С++ - в Си нет ссылок, поэтому изменение будет явным образом, через указатель. Следовательно такие параметры банально видны:

Код: [Выделить]

foo(a,b,&c,d,&e);


[Geniepro]

Если судить о простоте языка не по его "арифметике синтаксиса", а по длине руководства по стилю кодирования, то хаскель получается куда уж проще оберонов:

Можно судить по чему угодно, хоть по длине ...ки. Не проще пойти куда-нибудь класс в 9-й, хотя бы, и там посудить "о простоте языка"?

Эта разница просто так резко бросилась в глаза, что не смог умолчать о ней.

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

И в чём же здесь некорректность?

[Илья Ермаков]

Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))

[Geniepro]

VAR-параметры это да, проблема... Причем по хорошему, эта проблема должна бы решаться на уровне языка.

В этом плане мне даже больше нравится Си чем С++ - в Си нет ссылок, поэтому изменение будет явным образом, через указатель. Следовательно такие параметры банально видны:

Код: [Выделить]

foo(a,b,&c,d,&e);

Подход Си отстоен -- там слишком легко вместа адреса переменной "&c" передать её значение "c". В этом плане куда лучше ref- и out-параметры сишарпа:

Код: [Выделить]

foo(a, b, ref c, d, out e);

[Geniepro]

Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??

Любые программистские редакторы, в которых можно указывать размер табуляции в пробелах.
Допустим, один программист выставил в своём редакторе табуляцию в 4 пробела, другой -- в два пробела, третий оставил по умолчанию 8 пробелов (ну или он работает в блокноте).
Теперь представьте, что при оформлении кода табы смешиваются с пробелами -- у всех трёх программистов один и тот же текст будет выглядеть по разному, причём в худших случаях может получиться вообще нечитаемая каша.
Поэтому -- скажем нет табуляции!

так что разумное использование выравнивания очень приветствуется.

Лучше пишите так:

Код: [Выделить]

TYPE
  Event = RECORD
    date    : Date;
    time    : Time;
    location: Location
  END;

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

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

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

Принятый не только в КП, но и в той же Java, и ещё много где, стиль, где имена типов-классов-модулей-процедур - с большой буквы, а имена объектов-переменный - с маленькой, наверное, лучше всего... Объявлять с разной буквы экспортированные и неэкспортированные поля - как-то странно.

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

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

[valexey_u]

Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))

Тут следует заметить, что для профессионала и новичка/обучающегося простота ЯП разная. Простой для новичка ЯП может оказаться (и скорее всего окажется) сложным для профессионала. Сложным в применении.

[Geniepro]

Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))

Язык Haskell для детей

Оригинал: Haskell For Kids!

[Geniepro]

Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??

Любые программистские редакторы, в которых можно указывать размер табуляции в пробелах.
Допустим, один программист выставил в своём редакторе табуляцию в 4 пробела, другой -- в два пробела, третий оставил по умолчанию 8 пробелов (ну или он работает в блокноте).
Теперь представьте, что при оформлении кода табы смешиваются с пробелами -- у всех трёх программистов один и тот же текст будет выглядеть по разному, причём в худших случаях может получиться вообще нечитаемая каша.

Поэтому -- скажем нет табуляции!

так что разумное использование выравнивания очень приветствуется.

Лучше пишите так:

Код: [Выделить]

TYPE
  Event = RECORD
    date    : Date;
    time    : Time;
    location: Location
  END;

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

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

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

Принятый не только в КП, но и в той же Java, и ещё много где, стиль, где имена типов-классов-модулей-процедур - с большой буквы, а имена объектов-переменный - с маленькой, наверное, лучше всего... Объявлять с разной буквы экспортированные и неэкспортированные поля - как-то странно.

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

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