Alexey Maslov,


У нас есть внутренний инструмент coslint, написанный Сашей Кобловым, который пропагацию типов в выражениях делает на основе информации из #dim. (Да синтаксис многословен, и выглядит чуждо, и скорее не по мампсовому а по бейсиковому, но это единственной что есть и что будет)
Для Atelier будет написан свой linter (уже на java) но работать он будет по схожему принципу. Посему, считайте это forward compatble рекомендацией.

Alexey MaslovДавайте попробуем честно (без скрытой рекламы) ответить на простые вопросы. Вот мои варианты ответов.

Это не скрытая реклама, это опыт вынесенный из жизни. Сашин линтер берет информацию о типах из аргументов и #dim, и для того, чтобы сделать его более счастливым при анализе моего кода приходилось расставлять #dim. Даже и без линтера #dim добавляют читабельность коду, посему эту практику решили рекомендовать в своих проектах.

Еще раз, это рекомендация, и каждый волен её проигнорировать или принять к сведению. Мы свои аргументы рассказали.

Alexey MaslovВстречный вопрос: будет ли этот инструмент опубликован?

Может быть, как просить, много неподдерживаемого там замешано (API не будет никогда опубликовано, серверная поддержка там заморожена из-за Atelier, и все такое). Как минимум, можно попробовать поиграться с объектным кодом, для конкретной версии.

Давайте проведем это через официальные каналы?

С другой стороны, в Atelier линтер предполагатся реализовать на стороне IDE на Java. С использованием инфраструктуры созданной для Atelier. И сообщество здесь может помочь получить этот результат скорее раньше чем позже...

Alexey MaslovСпасибо, без исходников неинтересно. Если развитие заморожено, то тем более.

Непонятно, Алексей Игоревич, а почему неинтересно? Если этот инструмент будет делать свою уникальную функцию и делать в отсутствие альтернативы еще около года или более?

Кого-то смущает отсутствие исходников кода, который, скажем, раскрывает короткие инструкции в полные в Студии (Ctrl+E)? Или который делает рефакторинг переименованием? Или который увеличивает отступы в выделенном блоке? Нет, это всего лишь функции набора инструментов, используемого сегодня разработчиками в Cache'. И так получилост что у нас есть еще и (неидеальное, но) решение для еще одной полезной функции - статической проверки кода, которая, кстати, была сделана на базе того же набора классов, что и используется кодом рефакторинга. Да, этот серверный фреймворк, в силу текущих приоритетов, не будет меняться, а будет создаваться (когда-нибудь) клиентская поддержка. Но такая стабильность серверного API сегодня - даже может быть и хорошо, это значит, что при смене версии (неподдерживаемый официально) API не поплывет, и инструмент продолжит работать.

Да и кого из сообщества когда останавливал статус неподдерживаемого API? Если он был полезен уже _сегодня_? Вот вы в СП.АРМ и многие в других местах используете %Net.RemoteConnection, кого-то останавливает что это API давно deprecated? :)

P.S.
Если кому очень нужен COS linter - обращайтесь, мы найдем способ донести его (в том или ином виде) до ваших серверов.

doublefintШваров ЕвгенийСогласен, что set и do можно было бы вообще упразднить.
С set чревато, например
Я не понял чем чревато? (Пример был дан с if-ом старой формации, тогда как Женя говорил про ненужность ключевого слова if и do для парсинга присвоения и вызова функции при LL(n) грамматике)

Еще раз попытаюсь донести причины обязательного полного именования инструкций:
- мне все равно как пишут старые мампсеры, в своих внутренних проектах они могут по-прежнему использовать голый односимвольный MUMPS;
- но мне не все равно как код, который мы выложили в своих внешних open-source репозиториях, будет выглядеть в глазах новичков.

Я не хочу чтобы у них сразу взорвался мозг, и хочу чтобы наши проекты были хотя бы частично понятны любому новичку со средним бекграундом с JavaScript/Basic/другой язык общего назначения. С первого взгляда. Это сложная, но решаемая задача: надо пытаться писать писать просто, без извращенных идиом, без точечного синтаксиса, правильно используя отступы в блоках "нового" вида, разумно комментируя и разумно именуя.

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

doublefint,

Если cчитать $ как "Uppercase S" то вполне CamelCase получается! :)