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

[Geniepro]

Начал писать руководство по стилю кодирования. За образец взял документ Ada Quality and Style Guide, pdf-версия которого содержит 377 страниц.
Подумал -- ну, Обероне же проще Ады, так что страниц будет намного меньше...

Ну, начало положено, дальше продолжу...

[valexey_u]

До кучи вот соглашения принятые в ББ. Возможно стоит взять за отправную точку их.

[igor]

Начал писать руководство по стилю кодирования.

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

[Geniepro]

Начал писать руководство по стилю кодирования.

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

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

[igor]

Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!

[Geniepro]

Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!

Ну да, это стандартный инструмент у тех же ада-программеров -- Reformat.
Правда, почему-то мне не удалось заставить его запуститься в Ada-студии GPS... ))

[valexey_u]

Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!

Я не слишком люблю подобное автоформатирование по двум причинам:
1) коментарии могут оказаться в самых необычных местах.
2) убивается авторское форматирование некоторых специфических штук, ну например некоторые вещи в коде удобно оформить табличками.

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

[igor]

2) убивается авторское форматирование некоторых специфических штук

Согласен с замечанием. Самому лучше вручную придерживаться стиля, и не пользоваться автоформатом.

[Geniepro]

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

Snap Framework Haskell Style Guide

Минимальнейший текст, а вроде и не прибавить к нему ничего -- всё что надо, указано! о_О
Вот как надо проектировать языки -- что бы нетрудно было на них правильно оформлять программы )))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GetXxxXxx(aa, bb, cc, cc)

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

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

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