Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Сентябрь 01, 2013, 06:20:56 pm
-
Начал писать руководство по стилю кодирования. За образец взял документ Ada Quality and Style Guide (http://en.wikibooks.org/wiki/Ada_Style_Guide), pdf-версия которого содержит 377 страниц.
Подумал -- ну, Обероне же проще Ады, так что страниц будет намного меньше...
Ну, начало положено, дальше продолжу...
-
До кучи вот соглашения принятые в ББ. Возможно стоит взять за отправную точку их.
-
Начал писать руководство по стилю кодирования.
Посмотрел. Думаю, что документ весьма полезен, особенно для начинающих.
Да, привет любителям пропорциональных шрифтов :D
-
Начал писать руководство по стилю кодирования.
Посмотрел. Думаю, что документ весьма полезен, особенно для начинающих.
Да, привет любителям пропорциональных шрифтов :D
Пропорциональные шрифты, похоже, используют лишь блекбоксёры и ненавидимый ими Страуструп )))
-
Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!
-
Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!
Ну да, это стандартный инструмент у тех же ада-программеров -- Reformat.
Правда, почему-то мне не удалось заставить его запуститься в Ada-студии GPS... ))
-
Кстати, если удастся формализовать стилистические правила, то это открывает новые возможности. Допустим, загружаешь в свой специализированный редактор чужые сырцы, нажимаешь кнопку "Исправить стиль", и - вуаля!
Я не слишком люблю подобное автоформатирование по двум причинам:
1) коментарии могут оказаться в самых необычных местах.
2) убивается авторское форматирование некоторых специфических штук, ну например некоторые вещи в коде удобно оформить табличками.
Но иногда да, код такой, что явно там ни комментов ни табличек, и читать такой код совершенно невозможно. В этом случае уж лучше автоформат.
-
2) убивается авторское форматирование некоторых специфических штук
Согласен с замечанием. Самому лучше вручную придерживаться стиля, и не пользоваться автоформатом.
-
Если судить о простоте языка не по его "арифметике синтаксиса", а по длине руководства по стилю кодирования, то хаскель получается куда уж проще оберонов:
Snap Framework Haskell Style Guide (http://snapframework.com/docs/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-й, хотя бы, и там посудить "о простоте языка"? :)
Я просто не понимаю, зачем оригинальничать и делать заведомо некорректные высказывания, чисто чтоб сказать.
-
Пропорциональные шрифты, похоже, используют лишь блекбоксёры и ненавидимый ими Страуструп )))
Страуструп - неглупый мужик. В частности, его понимание необходимости и особенностей "универсального императивного языка уровня 3GL" совершенно отлично сформулировано (привет функциональщикам).
Если учесть также его признание, что "аналог С++ можно бы сделать в 10 раз компактнее", то ещё интереснее.
Мешало всегда желание доминирования в среде сишников за счёт охвата обычного С - и предрассудок "нельзя навязывать программисту только один способ что-то сделать, надо давать выбор". Короче, странный аргумент, что каждый пользователь языка имеет право сойти с ума своим неповторимым образом.
Эти два заблуждения Страуструпа, уверен, сознательные, т.к. человек поставил своей целью сделать мега-популярный язык. И только во вторую очередь ещё и язык, каким-то объективным требованиям соответствующий.
-
Некоторые редакторы умеют делать "умное выравнивание" при использовании символов табуляции для выравнивания строк кода. Однако такие редакторы не слишком распространены и чаще всего использование табуляции приводит к плачевному разрушению форматирования программ при различающихся настройках в разных редакторах.
Поэтому использование символов табуляции в текстах программ крайне нежелательно.
Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??
Не знаю как блокнот, а я вот сам плачевно реагирую на табуляцию :-)
На самом деле оформление кода с помощью табуляций возможно только в случае если у нас есть еще один вспомогательный элемент выравнивания типа ББшной линейки. Во всех остальных случаях моноширинный шрифт + пробелы предпочтительнее.
-
так что разумное использование выравнивания очень приветствуется.
Лучше пишите так:
TYPE
Event = RECORD
date : Date;
time : Time;
location: Location
END;
Угу, и если нужно добавить новое поле, то я буду перебивать отступы в 5 соседних? Удивительно, как часто забывается, что "программёр больше не писатель, а менятель".
Специальный редактор/плагин будем искать для такого? Особенно, после того, как отказались от табуляций, потому что хотим работать в гипотетических "любых редакторах"...
"Разумное использование выравнивания приветствуется..." - так разумное или чрезмерное? Что добавляет для читабельности вот это центрование двоеточий?
Вот будет семантическое редактирование - и табличка объявлений в таком редакторе, это дело. А изголяться так в тексте...
Предлагаю говорить о вкусе устриц с теми, кто их ел (а не пробовал) :-)
Я на работе именно так оформляю код на Objective-C (и не только я - это распространенная практика). В результате во-первых код выглядит эстетичней и читается легче, а во-вторых обозначенных проблем я не наблюдаю. То есть да, иногда добавляешь поле и нужно что-то там подравнять, ну дык это не проблема вовсе. В любом случае код читается много чаще чем редактируется.
Разумное выравнивание - это означает что если у нас подряд идет вначале 2 поля в 2 буквы, а затем 3 поля с длиной названия в 20 букв, то, видимо, не стоит их выравнивать одинаково.
Выравнивание нужно не ради выравнивания, а ради читабельности и уменьшения энтропии в коде.
-
Разумное использование пустых строк для группирования логически связанных блоков программы повышает её понятность при чтении.
Лучше бы пропагандировать ограничение размера процедур в среднем 15 строками и запрещать вложенность циклов в рамках одной процедуры (кроме случаев типа FOR x .... DO FOR y... DO FOR z ... DO...).
И тогда логически "связанные блоки программы" будут оформлены, как и следует, отдельными процедурами.
Создание каждой новой процедуры не бесплатно, и несет некий синтаксический оверхед. Так что много-много очень мелких процедур также плохо. Когда оформляешь код, нужно думать о количестве необходимых операций (движения глазами, перемотка текста туда-сюда в редакторе) которые читателю придется совершить чтобы разобраться в оном коде. Именно это число операций нужно минимизировать, а не тупо следовать какому-то жесткому правилу (длина кода не больше такого-то, бить на максимальное колличество процедур и так далее).
-
Не знаю, как это реализовывать в плоском тексте...
Но я использую оформление подчёркиванием выходных параметров при вызове процедур:
GetXxxXxx(aa, bb, cc, cc)
А для var-аргументов? OUT-параметров в Обероне нет.
-
Создание каждой новой процедуры не бесплатно, и несет некий синтаксический оверхед. Так что много-много очень мелких процедур также плохо. Когда оформляешь код, нужно думать о количестве необходимых операций (движения глазами, перемотка текста туда-сюда в редакторе) которые читателю придется совершить чтобы разобраться в оном коде. Именно это число операций нужно минимизировать, а не тупо следовать какому-то жесткому правилу (длина кода не больше такого-то, бить на максимальное колличество процедур и так далее).
Полностью согласен. Но для алгоритмоёмкого кода моё правило как раз применимо на 100%. Оно соответствует и ходу проектирования алгоритма пошаговой детализацией. (Кстати, именно такую культуру в своих учебниках настойчиво, с первых занятий, прививает Кушниренко - в школьном и в мехматовском вузовском).
Согласен с тобой про мясистый (как vlad любит выражаться) практически линейный код какой-нибудь инициализации, или гуя и т.п. Там часто лучше оставить линейно простынёй, проредив пробелами.
Причин не обособить любую циклическую обработку в отдельную процедуру - нет, кроме оптимизаций. Такая обработка, по любому, достойна быть сокрытой на другой уровень, чтобы на более высоком осталась лишь последовательность...
-
А для var-аргументов? OUT-параметров в Обероне нет.
То же самое... Подчёркиваем эффект изменения переменной, а уж входно-выходное оно или просто выходное - вторично.
-
А для var-аргументов? OUT-параметров в Обероне нет.
То же самое... Подчёркиваем эффект изменения переменной, а уж входно-выходное оно или просто выходное - вторично.
VAR-параметры это да, проблема... Причем по хорошему, эта проблема должна бы решаться на уровне языка.
В этом плане мне даже больше нравится Си чем С++ - в Си нет ссылок, поэтому изменение будет явным образом, через указатель. Следовательно такие параметры банально видны:
foo(a,b,&c,d,&e);
-
Если судить о простоте языка не по его "арифметике синтаксиса", а по длине руководства по стилю кодирования, то хаскель получается куда уж проще оберонов:
Можно судить по чему угодно, хоть по длине ...ки. Не проще пойти куда-нибудь класс в 9-й, хотя бы, и там посудить "о простоте языка"? :)
Эта разница просто так резко бросилась в глаза, что не смог умолчать о ней.
Я просто не понимаю, зачем оригинальничать и делать заведомо некорректные высказывания, чисто чтоб сказать.
И в чём же здесь некорректность?
-
Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))
-
VAR-параметры это да, проблема... Причем по хорошему, эта проблема должна бы решаться на уровне языка.
В этом плане мне даже больше нравится Си чем С++ - в Си нет ссылок, поэтому изменение будет явным образом, через указатель. Следовательно такие параметры банально видны:
foo(a,b,&c,d,&e);
Подход Си отстоен -- там слишком легко вместа адреса переменной "&c" передать её значение "c". В этом плане куда лучше ref- и out-параметры сишарпа:
foo(a, b, ref c, d, out e);
-
Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??
Любые программистские редакторы, в которых можно указывать размер табуляции в пробелах.
Допустим, один программист выставил в своём редакторе табуляцию в 4 пробела, другой -- в два пробела, третий оставил по умолчанию 8 пробелов (ну или он работает в блокноте).
Теперь представьте, что при оформлении кода табы смешиваются с пробелами -- у всех трёх программистов один и тот же текст будет выглядеть по разному, причём в худших случаях может получиться вообще нечитаемая каша.
Поэтому -- скажем нет табуляции!
так что разумное использование выравнивания очень приветствуется.
Лучше пишите так:
TYPE
Event = RECORD
date : Date;
time : Time;
location: Location
END;
Угу, и если нужно добавить новое поле, то я буду перебивать отступы в 5 соседних? Удивительно, как часто забывается, что "программёр больше не писатель, а менятель".
Да, это не займёт много времени, а если у вас запись растянулась на кучу строк/несколько экранов, то такую жуть нужно рефакторить -- разбивать на несколько записей.
Имена неэкспортированных полей записей, параметров и локальных переменных процедур следует начинать со строчной буквы (в нижнем регистре).
Принятый не только в КП, но и в той же Java, и ещё много где, стиль, где имена типов-классов-модулей-процедур - с большой буквы, а имена объектов-переменный - с маленькой, наверное, лучше всего... Объявлять с разной буквы экспортированные и неэкспортированные поля - как-то странно.
Да, тут нужно всё хорошенько обдумать с разных сторон. Ну, для того и нужны форумы...
Цель всех этих стайл-гайдов в том, что бы программы от разных производителей были офромлены одинаково, как в языке Ада, например. Вот, valexey часто упоминает о том, что какую бы программу на Аде не откроешь -- всё привычно и понятно. К этому и нужно стремиться, я считаю...
-
Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))
Тут следует заметить, что для профессионала и новичка/обучающегося простота ЯП разная. Простой для новичка ЯП может оказаться (и скорее всего окажется) сложным для профессионала. Сложным в применении.
-
Попробуйте кого-нибудь научить Хаскелю, чтобы болтать о простоте ))
Язык Haskell для детей (http://it-talk.org/topic15355.html)
Оригинал: Haskell For Kids! (http://cdsmith.wordpress.com/2011/08/03/haskell-for-kids-introduction/)
-
Это какие такие редакторы "плачевно" реагируют на табуляцию? Блокнот, что ли??
Любые программистские редакторы, в которых можно указывать размер табуляции в пробелах.
Допустим, один программист выставил в своём редакторе табуляцию в 4 пробела, другой -- в два пробела, третий оставил по умолчанию 8 пробелов (ну или он работает в блокноте).
Теперь представьте, что при оформлении кода табы смешиваются с пробелами -- у всех трёх программистов один и тот же текст будет выглядеть по разному, причём в худших случаях может получиться вообще нечитаемая каша.
Поэтому -- скажем нет табуляции!
так что разумное использование выравнивания очень приветствуется.
Лучше пишите так:
TYPE
Event = RECORD
date : Date;
time : Time;
location: Location
END;
Угу, и если нужно добавить новое поле, то я буду перебивать отступы в 5 соседних? Удивительно, как часто забывается, что "программёр больше не писатель, а менятель".
Да, это не займёт много времени, а если у вас запись растянулась на кучу строк/несколько экранов, то такую жуть нужно рефакторить -- разбивать на несколько записей.
Имена неэкспортированных полей записей, параметров и локальных переменных процедур следует начинать со строчной буквы (в нижнем регистре).
Принятый не только в КП, но и в той же Java, и ещё много где, стиль, где имена типов-классов-модулей-процедур - с большой буквы, а имена объектов-переменный - с маленькой, наверное, лучше всего... Объявлять с разной буквы экспортированные и неэкспортированные поля - как-то странно.
Да, тут нужно всё хорошенько обдумать с разных сторон. Ну, для того и нужны форумы...
Цель всех этих стайл-гайдов в том, что бы программы от разных производителей были офромлены одинаково, как в языке Ада, например. Вот, valexey часто упоминает о том, что какую бы программу на Аде не откроешь -- всё привычно и понятно. К этому и нужно стремиться, я считаю...
-
чёрт, из-за лагов два раза отправил предыдущее сообщение ))
-
VAR-параметры это да, проблема... Причем по хорошему, эта проблема должна бы решаться на уровне языка.
В этом плане мне даже больше нравится Си чем С++ - в Си нет ссылок, поэтому изменение будет явным образом, через указатель. Следовательно такие параметры банально видны:
foo(a,b,&c,d,&e);
Подход Си отстоен -- там слишком легко вместа адреса переменной "&c" передать её значение "c". В этом плане куда лучше ref- и out-параметры сишарпа:
foo(a, b, ref c, d, out e);
Сложно. Нормальный компилятор (а в случае С++ - любой компилятор) долбанет по башке варнингом, а то и еррором.
-
Язык Haskell для детей (http://it-talk.org/topic15355.html)
Профанация.
Я могу написать "С++ для детей". И такое даже есть...
Меня брат в 8 классе "подсаживал" на С++, после QBasic. Представляю, что это значит: тупо какой-то копипаст из книжек, с видимостью полезного эффекта и всякими развлекательными рассказами про то, что "класс - это холодильник, в нём лежат продукты" и т.п.
Эталон учебного курса - Кушниренко. Если интересуетесь образованием, почитайте его "12 лекций о том, для чего нужен школьный курс информатики и как его преподавать" (всё его есть здесь: http://www.niisi.ru/kumir/books.htm)
К этому ни добавить, не убавить (и устареть это тоже не может).
Т.е. любой курс полезно сравнивать с Кушниренко по прозрачности/понятности/фундаментальности/формированию мышления.
-
Меня брат в 8 классе "подсаживал" на С++, после QBasic. Представляю, что это значит: тупо какой-то копипаст из книжек, с видимостью полезного эффекта и всякими развлекательными рассказами про то, что "класс - это холодильник, в нём лежат продукты" и т.п.
А чем, по такому описанию, класс хуже структуры или record'a? :-) Названием?
-
Меня брат в 8 классе "подсаживал" на С++, после QBasic. Представляю, что это значит: тупо какой-то копипаст из книжек, с видимостью полезного эффекта и всякими развлекательными рассказами про то, что "класс - это холодильник, в нём лежат продукты" и т.п.
А чем, по такому описанию, класс хуже структуры или record'a? :-) Названием?
:D :D :D :D Алексей , проблема в том, что программирование ( а также обучение ему ) не сводится к "холодильникам" - рассматривать нужно некоторый определенный комплекс(обьектно- понятийный, аудиторию, окружение и взаимодействие между этими компонентами).
-
Меня брат в 8 классе "подсаживал" на С++, после QBasic. Представляю, что это значит: тупо какой-то копипаст из книжек, с видимостью полезного эффекта и всякими развлекательными рассказами про то, что "класс - это холодильник, в нём лежат продукты" и т.п.
А чем, по такому описанию, класс хуже структуры или record'a? :-) Названием?
:D :D :D :D Алексей , проблема в том, что программирование ( а также обучение ему ) не сводится к "холодильникам" - рассматривать нужно некоторый определенный комплекс(обьектно- понятийный, аудиторию, окружение и взаимодействие между этими компонентами).
Нужно в первую очередь наглядно показывать нафига вообще все эти структуры нужны. Помню когда в школе (самостоятельно) изучал Си (не С++!), долго не мог понять нафига эти структуры нужны вообще - ведь они ничего нового по сравнению с массивом и отдельными переменными не привносят. Ну запись доступа чутка другая, и все. Явно же лишняя сущность и усложнение! Ведь и без них все отличненько работает.
Кстати, разбиение на отдельные функции - из той же оперы. Отличненько все работает и в едином неделимом main'e! Особенно если редактор поддерживает фолдинг. Особенно если это именованный фолдинг.
-
Нужно в первую очередь наглядно показывать нафига вообще все эти структуры нужны....
;D ;D ;D ;D это всего лишь элемент.. причем, в зависимости от целей обучения необязательный, а в контексте некоторых типов аудиторий качественно не реализуемый.
-
Эталон учебного курса - Кушниренко. Если интересуетесь образованием, почитайте его "12 лекций о том, для чего нужен школьный курс информатики и как его преподавать" (всё его есть здесь: http://www.niisi.ru/kumir/books.htm)
К этому ни добавить, не убавить (и устареть это тоже не может).
Т.е. любой курс полезно сравнивать с Кушниренко по прозрачности/понятности/фундаментальности/формированию мышления.
Я по учебнику Кушниренко "ОИВТ" (ещё советскому) в школе информатику изучал ))) До сих пор ещё у меня есть эти учебники...
-
Учебник у них очень "сухой" (ограничение объёма при издании), стоит почитать их "12 лекций...", тогда становится понятно, для чего и почему в учебнике каждое решение, как по нему учителю работать - и вообще, насколько продуманный курс.
(Я, кстати, то ли в 2007-м, то ли в 2006-м привозил Info21 этот учебник - но он его не впечатлил... А потом Info21 раскопал эти "12 лекций" - и впечатлился :) ).
-
Как дела, работа идёт? Находил в интернете стандарты кодирования микроконтроллёров на си. Стандарт МИСРА. Там довольно кратко и содержательно, описано как кодировать. Возможно это поможет.
Языци заморския
http://automotive.roger.free.fr/articles/miscprev.pdf
Великий русский язык.
http://andromega.narod.ru/doc/micrium_an_2000_rus.pdf
Можно просматривать в онлайне.
-
Ещё на русском http://andromega.narod.ru/doc/iar_ew_misra_c_rus.pdf
-
Как дела, работа идёт?
Работа стоит )) Надо бы продолжить на выходных...
-
Народ, гляньте мой Оберонистый код, и напишите список замечаний по стилю плиз.
Одно примечание - когда в одной портянке текста (одном файле, или там в одном текстовом редакторе) находится несколько модулей, то удобней потроха модуля (процедуры, переменные и так далее) писать одним отступом, когда же в одном файле один модуль, но этот отступ не нужен. Это мое IMHO.
-
Народ, гляньте мой Оберонистый код, и напишите список замечаний по стилю плиз.
Ещё раз, какой именно код? ))
Одно примечание - когда в одной портянке текста (одном файле, или там в одном текстовом редакторе) находится несколько модулей, то удобней потроха модуля (процедуры, переменные и так далее) писать одним отступом, когда же в одном файле один модуль, но этот отступ не нужен. Это мое IMHO.
Обычно, всё же, один модуль -- один файл...
-
http://oberspace.dyndns.org/index.php/topic,541.msg18024.html#msg18024
Этот
-
http://oberspace.dyndns.org/index.php/topic,541.msg18024.html#msg18024
Этот
В общем и в целом нормально, суть руководства по стилю ухвачена.
Но есть претензии:
1) Аргументы процедур надо отделять друг от друга пробелами:
Правильно:
PROCEDURE Line*(x0, y0, x1, y1 : REAL);
P.SetSize(640, 360);
Неправильно:
PROCEDURE Line*(x0,y0,x1,y1 : REAL);
P.SetSize(640,360);
2) Операторы в выражениях так же следует отделять от их аргументов пробелами:
Правильно:
h := 0.66 * h;
Неправильно:
h := 0.66*h;
3) Не знаю, как лучше делать в таких случаях:
так: TYPE
ProcessingType* = POINTER TO RECORD END; (* dummy type *)
CallbackType* = PROCEDURE;
VAR
MouseX* : REAL;
MouseY* : REAL;
Width* : INTEGER;
Height* : INTEGER;или так: TYPE
ProcessingType * = POINTER TO RECORD END; (* dummy type *)
CallbackType * = PROCEDURE;
VAR
MouseX * : REAL;
MouseY * : REAL;
Width * : INTEGER;
Height * : INTEGER;или даже так: TYPE
ProcessingType *= POINTER TO RECORD END; (* dummy type *)
CallbackType *= PROCEDURE;
VAR
MouseX *: REAL;
MouseY *: REAL;
Width *: INTEGER;
Height *: INTEGER;
-
3) Не знаю, как лучше делать в таких случаях:
На мой взгляд, лучше первый вариант. Во втором варианте звёздочка выглядит как "умножить" и только сбивает с толку. Третий вариант тоже плох, потому что маркер семантически связан с идентификатором, а не с типом. Стремление представить инфу об экспорте в виде столбика понятно, - так нагляднее, - но здесь всё же лучше не перебарщивать.
-
3) Не знаю, как лучше делать в таких случаях:
На мой взгляд, лучше первый вариант. Во втором варианте звёздочка выглядит как "умножить" и только сбивает с толку. Третий вариант тоже плох, потому что маркер семантически связан с идентификатором, а не с типом. Стремление представить инфу об экспорте в виде столбика понятно, - так нагляднее, - но здесь всё же лучше не перебарщивать.
В первом варианте тоже недостаток -- эта звёздочка экспорта плохо заметна. Если бы хотя бы она была перед идентификатором...
И вообще, что мешало Вирту ввести ещё одно ключевое слово public? Если он стремился к ясности программ на своём языке, то не стоило так экономить на спичках -- только хуже получилось...
-
И вообще, что мешало Вирту ввести ещё одно ключевое слово public?
А если это слово в комментарии указать, не равнозначно будет?
-
И вообще, что мешало Вирту ввести ещё одно ключевое слово public?
А если это слово в комментарии указать, не равнозначно будет?
Нет, ведь комментарии необязательны, а значит реально мало кто будет указывать.
-
Народ, гляньте мой Оберонистый код, и напишите список замечаний по стилю плиз.
Кстати да, комментариев вапще недостаточно )))
-
И вообще, что мешало Вирту ввести ещё одно ключевое слово public?
Всё это расширизмы и непотребство. :)
И вообще, что мешало Вирту ввести ещё одно ключевое слово public?
А если это слово в комментарии указать, не равнозначно будет?
Как раньше на паскале?
end (* имя функции*);
while
end (* while*) и т.д
TYPE
ProcessingType * = POINTER TO RECORD END; (* dummy type *)
CallbackType * = PROCEDURE;
VAR
MouseX * : REAL;
MouseY * : REAL;
Width * : INTEGER;
Height * : INTEGER;
Я голосую за этот вариант.
-
TYPE
ProcessingType * = POINTER TO RECORD END; (* dummy type *)
CallbackType * = PROCEDURE;
VAR
MouseX * : REAL;
MouseY * : REAL;
Width * : INTEGER;
Height * : INTEGER;
Я голосую за этот вариант.
А если я хочу так записать:
VAR
MouseX*, MouseY* : REAL; (* позиция курсора мыши *)
Width*, Height* : INTEGER; (* размеры окна *)
, то как мне отступы делать?
-
А если я хочу так записать: VAR
MouseX*, MouseY* : REAL; (* позиция курсора мыши *)
Width*, Height* : INTEGER; (* размеры окна *)
, то как мне отступы делать?
Да, вопрос, конечно, интересный.
Можно было бы, конечно, так: VAR
MouseX * : REAL; (* позиция курсора мыши -- координата X *)
MouseY * : REAL; (* позиция курсора мыши -- координата Y *)
Width * : INTEGER; (* размеры окна -- ширина *)
Height * : INTEGER; (* размеры окна -- высота *)
Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...
-
Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...
В приведённых примерах координаты (или там размеры) относятся к одной сущности (курсор мыши), поэтому их разделять не целесообразно. Большой беды, конечно, не будет, если их записать на разных строчках, но слишком уж утомительно подробно получается (даже комментарии частично дублируют друг друга).
-
Такие вопросы, как количество переменных в одной строке списка экспорта, тоже надо рассмотреть и к какому-то соглашению прийти...
В приведённых примерах координаты (или там размеры) относятся к одной сущности (курсор мыши), поэтому их разделять не целесообразно. Большой беды, конечно, не будет, если их записать на разных строчках, но слишком уж утомительно подробно получается (даже комментарии частично дублируют друг друга).
Такие связанные сущности принято объединять в структуры (записи), вообще-то...
-
Такие связанные сущности принято объединять в структуры (записи), вообще-то...
Я бы вообще предложил запретить нотацию "через запятую". Даже для связанных сущностей. А не связанные сущности отделять пустой строкой. Стремление в обероновских исходниках все упрятать в одну строку никогда не радовало глаз...
P.S. В С тоже можно лепить поля через запятую. В итоге во всех вменяемых исходниках это не практикуется.
-
Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.
-
Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.
Я за 4.
-
Предлагаю использовать отступ либо в 3 пробела (как в Аде) либо вообще в 4 - во-первых в этом случае отступы видны лучше, во-вторых в этом случае уровень вложенности конструкций будет получаться меньше.
Я за 4.
А может сразу 8 -- как в линуксе? И вапще не пробелы, а табуляцию? ))) Вложенность больше 3 будет трудно создавать при ограничении в 80 символов в строке )))
-
И еще вопрос - делать отступ для процедур и прочих потрохов модуля, или нет?
MODULE A;
PROCEDURE Foo;
BEGIN
END Foo;
END A.
MODULE A;
PROCEDURE Foo;
BEGIN
END Foo;
END A.
Нужно учесть, что начало модуля и конец модуля на один экран практически никогда не попадают одновременно.
-
Если имеет смысл для отделения того, что это код до BEGIN модуля и после. Я пока делаю для всего отступы, привык в 1С, мне так удобнее воспринимать (наверное привычка).
-
Если имеет смысл для отделения того, что это код до BEGIN модуля и после. Я пока делаю для всего отступы, привык в 1С, мне так удобнее воспринимать (наверное привычка).
Штука в том, что на экране мы обычно видим что-то вроде набора процедур модуля. Которые зачем-то сдвинуты на один отступ от края. При этом BEGIN..END секция модуля вообще часто не используется, а если и используется, то она мала.
Также следует учитывать, что чем больше отступов тем хуже они читаются. Первый отступ - читается лучше всего, и глупо его тратить на то что и так очевидно (очевидно что ВСЕ процедуры находятся в каком-то модуле, не бывает процедур вне модуля).
-
Ну так я и высказал мысль, что это разумно :) , но после бегин все же буду отсупы делать
-
Прочел руководство:
1) я за 4 пробела;
2) выравнивание кончено, удобно смотреть, но если редактор не поддерживает, специально делать точно буду (имею в виду выравнивание знаков равно и т.п.). Хотя выравнивания например при переносе параметров процедур на другую строку и т.п. однозначно нужны
3) Согласен про пустые строки, однозначно надо разделять
4) уже привык, что один оператор, одна строка, мне и читать код так обычно легче;
5) абревиатуры да, лучше не использовать
6) по поводу начинать ли с большой или малой буквы идентификаторы, пока не знаю (обычно пишу с большой), но уж с экспортом, мне кажется, это точно не должно быть связано
-
Нужно учесть, что начало модуля и конец модуля на один экран практически никогда не попадают одновременно.
Да, отступ для этого случая не имеет смысла.
-
Нужно учесть, что начало модуля и конец модуля на один экран практически никогда не попадают одновременно.
Да, отступ для этого случая не имеет смысла.
Мне тоже кажется отступ лишним.
Но как тогда быть с вложенными процедурами?
Можно в принципе делать так:
1. В модуле первый уровень без отступа (для IMPORT, CONST, VAR, TYPE, PROCEDURE, BEGIN)
2. В процедуре делать отступ (для CONST, VAR, TYPE, PROCEDURE)
-
Ну так я и высказал мысль, что это разумно :) , но после бегин все же буду отсупы делать
Дык после BEGIN да, отступы нужны и важны. Как-то так:
MOFULE A;
CONST
pi = 3.1415;
TYPE
Foo = RECORD END;
VAR
some : INTEGER;
PROCEDURE Boo();
CONST
e = 2.7;
TYPE
Arr = ARRAY 10 OF CHAR;
VAR
i : INTEGER;
PROCEDURE Inner();
BEGIN
i := 0;
END Inner;
BEGIN
i := 0;
END Boo;
PROCEDURE Boo1();
CONST
e = 2.7;
TYPE
Arr = ARRAY 10 OF CHAR;
VAR
i : INTEGER;
PROCEDURE Inner();
BEGIN
i := 0;
END Inner;
BEGIN
i := 0;
END Boo1;
PROCEDURE Boo2();
CONST
e = 2.7;
TYPE
Arr = ARRAY 10 OF CHAR;
VAR
i : INTEGER;
PROCEDURE Inner();
BEGIN
i := 0;
END Inner;
BEGIN
i := 0;
END Boo2;
BEGIN
some := 42;
Boo;
Boo1;
Boo2;
END A.
Ну и как это все смотрится на gist'ах например:
вариант с 4 пробелами: https://gist.github.com/valexey/7450244
вариант с 3 пробелами: https://gist.github.com/valexey/7450264
По моему, 3 пробела смотрятся лучше (на даром же Ада-поклонники именно 3 используют).
-
По моему, 3 пробела смотрятся лучше (на даром же Ада-поклонники именно 3 используют).
Только 4! :)
-
По моему, 3 пробела смотрятся лучше (на даром же Ада-поклонники именно 3 используют).
Только 4! :)
rationale? :-) Ну, то есть я могу обосновать почему в данном случае 3 лучше чем 4 и лучше чем 2.
-
rationale? :-) Ну, то есть я могу обосновать почему в данном случае 3 лучше чем 4 и лучше чем 2.
Не только на обероне приходится писать некоторым ;) А в других местах принято 4. Зачем добавлять искусственную специфику? Пусть даже она и лучше в абсолюте.
-
rationale? :-) Ну, то есть я могу обосновать почему в данном случае 3 лучше чем 4 и лучше чем 2.
Не только на обероне приходится писать некоторым ;) А в других местах принято 4. Зачем добавлять искусственную специфику? Пусть даже она и лучше в абсолюте.
Ну да, некоторые вот еще на Аде пишут, а там 3 пробела таки :-)
Обосную:
VAR
something
смотрится лучше чем:
VAR
something
То есть отступ в 3 пробела диктуется тем, что самое короткое частовстречающееся слово после которого делается этот отступ (VAR) длиной ровно в 3 символа.
-
Ну, то есть я могу обосновать почему в данном случае 3 лучше чем 4 и лучше чем 2.
Ну обоснуй, чем 2 пробела - плохо.
(Сам я всегда использую 2 пробела :) ).
-
Можно в принципе делать так:
1. В модуле первый уровень без отступа (для IMPORT, CONST, VAR, TYPE, PROCEDURE, BEGIN)
А я уже давно так делаю.
-
Ну, то есть я могу обосновать почему в данном случае 3 лучше чем 4 и лучше чем 2.
Ну обоснуй, чем 2 пробела - плохо.
(Сам я всегда использую 2 пробела :) ).
Обосновываю - во-первых 2 пробела провоцируют на глубокую вложенность конструкций. Ибо отлично все помещается по ширине на экране. Во-вторых два пробела маловато - если уровень вложенности не первый а третий скажем, и начала и конца блока не видно одновременно (а так бывает), то этот третий сложно отличить от четвертого.
-
Да в некоторых редакторах, да с некоторыми шрифтами, да еще их размерами, 2 пробела сами по себе могут стать плохо различимыми.
Внутри процедур, думаю надо делать отступы для декларативной части (чтобы от того же модуля отличалось)
Да, возможно 3 пробела выглядят лучше, но как уже отметили, в 1С принято 4
-
Да в некоторых редакторах, да с некоторыми шрифтами, да еще их размерами, 2 пробела сами по себе могут стать плохо различимыми.
Внутри процедур, думаю надо делать отступы для декларативной части (чтобы от того же модуля отличалось)
Да, возможно 3 пробела выглядят лучше, но как уже отметили, в 1С принято 4
Код ведь не будет с 1Совский смешиваться. То есть в одном и том же файле. Поэтому не вижу проблем.
-
Код ведь не будет с 1Совский смешиваться. То есть в одном и том же файле. Поэтому не вижу проблем.
Если буду делать его в редакторе 1С (а это для меня удобно, т.к. там можно задать шаблоны кода), то менять для этого каждый раз настройки не хочется. Можно конечно использовать другой редактор (и пока использую, попеременно), но в итоге хотел бы перейти полностью на 1С со снегопатом (особенно если помогут обайд прикрутить к скинтиле именно в 1С).
-
ХОтя посмотрю, может быть настройки можно задавать программно (тогда привяжу их к расширению кода)
-
Или может сублиме имеет ActiveX компонент? Тогда можно будет его использовать. С редактором пока не особо заморачивался. Но раз тут к нему привязки делают, то чтобы быть "в струе" :)
-
Или может сублиме имеет ActiveX компонент? Тогда можно будет его использовать. С редактором пока не особо заморачивался. Но раз тут к нему привязки делают, то чтобы быть "в струе" :)
Свят-свят! Какой нафиг ActiveX в кроссплатформенной проге? И зачем? :-)
-
Имел в виду наоборот: сублиме как ActiveX компонент (чтобы встроить его в 1С, и использовать внутря)
ХОтя как понял, он платный, а период пробный какой? И к нему только на питоне плагины пишутся? На яваскрипте нету?
-
Имел в виду наоборот: сублиме как ActiveX компонент (чтобы встроить его в 1С, и использовать внутря)
ХОтя как понял, он платный, а период пробный какой? И к нему только на питоне плагины пишутся? На яваскрипте нету?
Пробный период бесконечный. Оно просто раз в 50 что-ли сохранений напоминает, что неплохо бы купить.
На яваскрипте только через связку с python<->node.js, был такой модуль в свое время. Не знаю насколько сейчас он актуален.
В виде компонента, сколь я понимаю, его нет.
-
Хотя смотрю по описанию, в нем есть почти все нужные функции, в том числе и автоподстановка шаблонов. Можно в принципе на него пересесть (по крайней мере по скриптам). Просто для меня надо будет немного удобнее сделать переключение между редакторами 1С и данным. Тогда позже познакомлюсь более подробно. Может действительно все нужное уже есть, а чего нет, так это в снегопате доделаю. Тогда питон пока не актуален.
-
Голосую за 3 пробела. Попробовал. Заценил. Няшка.
-
Можно в принципе делать так:
1. В модуле первый уровень без отступа (для IMPORT, CONST, VAR, TYPE, PROCEDURE, BEGIN)
Пораскинул мозгами, попробовал разные варианты и пришел к любопытному выводу.
Давно заметил что текст (любой) читать легче если слева есть пустое поле. В популярных IDE такое поле обычно есть. Несмотря на то, что оно выполняет другие задачи (отображение номеров строк, выделение строки при двойном щелчке и установка/отображение закладок с точками останова), в результате это выглядит как левый отступ в книге.
Например в ББ если не делать искусственный отступ, то при разворачивании окна на весь экран читать становится не комфортно.
Вывод: Отступ на первом уровне не нужен если IDE/редактор уже делает это.
-
Можно в принципе делать так:
1. В модуле первый уровень без отступа (для IMPORT, CONST, VAR, TYPE, PROCEDURE, BEGIN)
Пораскинул мозгами, попробовал разные варианты и пришел к любопытному выводу.
Давно заметил что текст (любой) читать легче если слева есть пустое поле. В популярных IDE такое поле обычно есть. Несмотря на то, что оно выполняет другие задачи (отображение номеров строк, выделение строки при двойном щелчке и установка/отображение закладок с точками останова), в результате это выглядит как левый отступ в книге.
Например в ББ если не делать искусственный отступ, то при разворачивании окна на весь экран читать становится не комфортно.
Вывод: Отступ на первом уровне не нужен если IDE/редактор уже делает это.
У нас вроде бы не планируется использование редакторов которые не делают это, так что вывод очевиден :-)
-
На самом деле оформление кода с помощью табуляций возможно только в случае если у нас есть еще один вспомогательный элемент выравнивания типа ББшной линейки. Во всех остальных случаях моноширинный шрифт + пробелы предпочтительнее.
Тык в нормальных редакторах кода табуляция и так по линейке работает. Как минимум это так в 1С и в Sublime Text 2/3.
-
На самом деле оформление кода с помощью табуляций возможно только в случае если у нас есть еще один вспомогательный элемент выравнивания типа ББшной линейки. Во всех остальных случаях моноширинный шрифт + пробелы предпочтительнее.
Тык в нормальных редакторах кода табуляция и так по линейке работает. Как минимум это так в 1С и в Sublime Text 2/3.
А где в sublime линейка? Кроме того, очевидно что их в документе должно быть несколько.
-
В настройках, где задается количество пробелов в табуляции.
Зачем несколько?
-
Давно подозревал, что многие противники табуляции просто не знают об этой фиче :)
-
В настройках, где задается количество пробелов в табуляции.
Зачем несколько?
Потому что в разных местах кода я по разному оформляю. Когда у меня табов нет в принципе, то пробелами я могу оформить везде как надо - тут у меня такая табличка, а вот тут эдакая лесенка. Это повышает выразительность кода существенно.
Когда у меня табы, то без нескольких линеек не обойтись. Причем я должен иметь возможность реально для каждого уровня табов задавать отступ, то есть как в составных документах ББ. Иначе получается ересь.
-
Табличек в коде не рисовал, потому с проблемами не сталкивался. :)
А для выравнивания кода вполне достаточно имхо.