bsl-language-server
bsl-language-server copied to clipboard
1c-syntax
[MOD] IncorrectLineBreak противоречие в диагностике
Диагностика
IncorrectLineBreak
Версия
1.10.0
Описание ошибки диагностики
Диагностика срабатывает на перенос параметров методов с лидирующей запятой
Пример кода
ВызовМетода(Параметр1
, Параметр2)
Скриншоты
Дополнительная информация
Диагностика противоречит самой себе в части переноса параметров и переноса выражений. В параметрах разделитель операндов должен быть расположен завершая строку, а в выражениях начиная строку. Более логично использовать разделитель начинающим строку символом - при стандартном форматировании так виднее, что эта строка продолжает выражение. Либо отключить проверку запятой, если есть уж такая неоднозначность ее использования.
Добрый день. Не совсем понимаю, откуда возникло предположение о разрешении запятой в начале строки. Диагностика в настройках по умолчанию всегда требует запятую в конце строки, а не в начале.
А кажется, что при переносе вызовов запятая тоже должна быть в начале новой строки, а не в конце. Поясню Решаемая диагностикой проблема - необходимо, чтобы в многострочных выражениях строки продолжения были бы явно видны при чтении кода. По-этому при переносах первым символом идет знак операции. Конфигуратор (стандартное IDE) форматирует многострочные вызовы без отступов, по-этому хочется, чтобы и в вызовах первым символом в переносах стоял знак - запятая. В текущей реализации диагностика для выражений сигнализирует о проблеме, а для вызовов наоборот ее кажется создает, уменьшает читабельность кода.
Для переносов есть конкретный стандарт, говорящий о том, что запятая должна быть в конце, диагностика его и проверяет :)
Оно конечно так, есть стандарт вендора. Но кажется, что он как-то ориентируется частью на логику решения проблемы, а частью на новое форматирование в EDT. Может быть возможно не столь строго следовать стандартам вендора? =) Не все вендорские стандарты бесспорны, часть из них кажется опирается просто на наличие большой кодовой базы, так сказать "так принято". А в данном случае получается, что стандарт (диагностика) просто противоречив - по сути одно и то же трактуется в разных случаях по-разному. Причем в одном из случаев еще и ухудшая внешний вид кода. По-этому и предлагаю изменить диагностику так, чтобы она придерживалась единой логики для всех ситуаций. Решая конечно проблему. Пусть даже в некотором противоречии стандарту вендора
Давайте ещё раз пример, где по вашему диагностика работает некорректно. А точнее два примера
В стандарте, если читать дословно, вообще ничего не сказано про запятые, есть только пример кода =) Ссылка на стандарт 1С переносов В пп. 2, 3.2, 5 при переносе операций, это арифметика и условия, знак операции ставится в начале строки, а в п. 4 про вызовы нет слов про запятые, но есть пример кода, где знак операции ставится в конце строки. Какие-то разные правила одного явления.
п. 2: ... при переносе знаки операции пишутся в начале строки (а не в конце предыдущей строки);
4. При необходимости параметры процедур, функций и методов следует переносить следующим образом:
* параметры выравниваются по началу первого параметра, либо предваряются стандартным отступом;
* закрывающая скобка и разделитель операторов ";" пишутся в той же строке, что и последний параметр;
* также допустим и способ форматирования, который предлагает функция автоформатирования в конфигураторе (см. п. 5).
Кажется смысл правила, решающий проблему, можно сформулировать так
В многострочных конструкциях новые строки должны начинаться со служебного символа / слова (знак операции, запятая, логическое условие, спецсимвол переноса строки)
примеры разницы запятая в конце - в строках переноса кажется, что они самостоятельны
Результат = ПолучитьФорму(Имя,
Параметры,
Владелец,
Уникальность,
Окно);
ОбъектДобавить(Транзакция,
Ссылка,
Идентификатор,
ВерсияНомер,
ТипИмя,
ЗаписьРежим,
ПроведениеРежим,
ИзменениеПометкиУдаления,
МоментВремени,
Точка);
запятая в начале - явно видно, что это продолжение
Результат = ПолучитьФорму(Имя
, Параметры
, Владелец
, Уникальность
, Окно);
ОбъектДобавить(Транзакция
, Ссылка
, Идентификатор
, ВерсияНомер
, ТипИмя
, ЗаписьРежим
, ПроведениеРежим
, ИзменениеПометкиУдаления
, МоментВремени
, Точка);
Параметр-то уже есть. Можно управлять допустимыми знаками в строках. Я скорее думаю про необходимость изменения поведения по умолчанию.
Лично у себя ставлю вот такую настройку. Если пригодится
"IncorrectLineBreak": {
"checkFirstSymbol": true,
"listOfIncorrectFirstSymbol": ";|\\);",
"checkLastSymbol": true,
"listOfIncorrectLastSymbol": "ИЛИ|И|OR|AND|,|\\+|-|/|%|\\*"
}
Здесь еще и закрывающая скобка убрана из первых символов. Иначе идет срабатывание на закрывающую скобку в условиях, например
Если НЕ ТочкаЭто
И (
(НЕ ПреСимволЧисло И НЕ ПреСимволТочка И ЧислоЭто)
ИЛИ (ПреСимволЧисло И НЕ ПреСимволТочка И НЕ ЧислоЭто)
) Тогда
а подобные группировки встречаются чаще, чем закрытие объявления/вызова на новой строке
почитал внимательно стандарт и пару соседних. действительно, именно про запятые ничего не нашел, только про точки с запятой, знаки арифметических операций и логические операторы.
на мой взгляд, расстановка запятых в начале строк при переносе выражений - практика скорее редкая, чем регулярная. Проблемы читаемости вполне (на мой взгляд опять же) решаются отступом внутри скобок. Так же при использовании запятой в начале строки это сбивает выравнивание параметров при переносе первого параметра на отдельную строку.
И хотя явного запрета/разрешения на такое форматирование (с запятой в начале строки) я не вижу, по умолчанию я бы оставил текущее поведение как есть. @shmalevoz для ваших проектов вы можете скорректировать listOfIncorrectFirstSymbol (вижу, вы это уже сделали) в настройках диагностики.
@1c-syntax/bsl-ls что думаете?
В sql часто запятые ставят перед строкой так обычно делают чтобы при добавлении удалении строк были изменения только в одной строке. Коммиты в гит более чистые.
По той же причине у объектов питона валидны запятые вконце списка, далее если там нет элемента.
Использовать такой стиль может быть удобно, но я бы не стал не имея автоформатера, загоняться самому все переводить так - особо учитывая что форматирование конструктора 1с будет отличаться, ну - нафиг.
Это выглядит как один из тех случаев, когда однозначно правильного варианта нет. В обоих есть какие то плюсы и минусы. Одним нравятся запятые вначале, другим в конце. Но главное, чтоб в проекте они были у всех одинаковые. И это решается "законодательно".
Судя по типовым, в 1С приняты запятые в конце. И в случае использования типовых (в том числе библиотек) лучше, чтоб стиль кода не отличался.
я пробовал стиль с запятыми в начале, но был почти бит :), так что предлагать данного решения точно не буду.
Если сильно хочется параметр, можно добавить, но... не думаю, что овчинка стоит выделки.
я предлагаю всего лишь убрать первые запятые из ошибок в текущей диагностике. мне кажется это приводит к проблемам при использовании стандартного форматирования конфигуратора. тем паче стандарт прямо это не запрещает ну и как надежду не брать 1Совский стандарт как конечную истину, есть там очень спорные места. а опираться на здравый смысл.
Ничего не понял. настройка есть, можно настраивать как душе угодно. Запятые в начале тоже пробовал когда то, отказался.
Стандарт про знаки он про + - И Или НЕ.
