Здравствуйте! подскажите пожалуйста, как правильно пользоваться меткой
из синтаксис помощника я понял что должно быть написано как то так:
...
Для i=1 по N+1 цикл
c[i-1][N]=-cf[i-1]/cf[m];
перейти метка123;
c[i-1][N]=50;
метка123;
КонецЦикла;
если кто то заинтересуется вот так работает:
Для i=1 по N+1 цикл
c[i-1][N]=-cf[i-1]/cf[m];
перейти ~метка123;
c[i-1][N]=50;
~метка123:
КонецЦикла;
да, разумеется я слышал =) мне только чтобы проверить правильность работы кода, который я с vba "перенес", просто так будет намного проще ошибку если что найти.
когда меня только учили программировать много-много лет назад, преподаватель снижал на 5 баллов оценку тому, кто использовал метки! использование меток - дурной тон программирования и неумение правильно выстраивать логику работы системы. потому мне не интересно как работают метки в 1с. и ни разу за много лет мне не пришлось пользоваться метками... и Вам это не нужно - правильно выстраивайте алгоритм работы подсистемы.
(4) alenakrr,
нам тоже рассказывали о том как плохо ставить метки, но позволю себе привести цитату от zfilin в его блоге, где он делится впечатлениями о прочтении книги Стива Макконела "Совершенный код".
ну и сама цитата:
Очень приятно то, в книге нет догматов. Автор в каждой главе советует "включать свою голову" и делать свой выбор в пользу того или иного способа сообразно ситуации. Например, нет категорического запрета использования "goto", а только внимательный анализ и выводы о том, что его использование приведет к проблемам и рекомендации избегать использования этого оператора. Но, как пишет сам Макконел, "если вы твердо уверены, что это единственный правильный способ"...
(5) Тот случай, когда искал информацию про "Перейти" и наткнулся на цитату из своего же блога. =)
И, да, кажется я сейчас нахожусь в ситуации, когда впервые было бы хорошо использовать безусловный переход.
Впрочем, я хочу еще хуже, я хочу безусловный переход по значению переменной типа того:
ИмяМетки = "М1";
Перейти ИмяМетки;
А это уже даже не грех, это грех + извращение. =)
Увы, 1С так не умеет.
(37) Через "Выполнить" не работает.
Пишет, что метка не найдена в процедуре, функции или теле модуля. Вполне логично, видимо у конструкции внутри "Выполнить" собственная область видимости меток.
использование меток - дурной тон программирования и неумение правильно выстраивать логику работы системы
Метки и GO TO - это отличный способ выйти из вложенных циклов (и единственный без дополнительных переменных). Также это единственный дешевый способ перейти в начало цикла без изменения итератора. В других случаях метки использовать не стоит - лучше подумать над логикой работы программы.
ЗЫ: Сам стал использовать метки только на 15-й год работы. Просто кое-кто еще до них не дорос )))
1) использование меток в коде приводит к замедлению быстродействия по сравнению со всеми возможными методами (функциями и процедурами)
2) программист, который использует метки КРАЙНЕ НЕПРОФЕССИОНАЛЕН:
а) поскольку не умеет выстраивать алгоритм работы задачи,
б) поскольку не умеет пользоваться функциями или процедурами с параметрами.
и в 1с метки оставлены не для того, чтобы их использовать, а чтобы подтвердить язык 1с.
Кстати, визуально этот оператор ничего не сокращает, а, наоборот, усложняет чтение кода, потому что приходится прыгать туда-сюда между экранами, чтобы понять что за чем выполняется.
вы хотите сказать что я изначально неправильно подошел к своей задаче(может и так) тогда в чем ошибка, и как бы вы "распорядились временем"?
1. есть не тривиальный расчет.
есть код(VBA) которым он реализован.(код в котором куча меток)
2. требуется реализовать его в 1с не используя внешние компоненты( т.к. в моем понимании использование внешней компоненты, требует наличия компилятора на ПК, на котором производится расчет)
3. мои действия
-переписать код(VBA) с учетом возможностей/особенностей 1с(синтаксиса и.т.д.).
это делаю для того чтобы если где то допущу ошибку, гоняя параллельно 2 отладчика легко её найти.
-оптимизировать рабочий код 1С(избавиться от меток)
мне казалось у меня правильный подход к решению задачи.
при лимите времени, тогда может стоит вызвать код VBA, а не переносить его в 1с?!
если excel не лицензирован, то возможно поможет open office?
переписывать под 1с при лимите времени можно только если Вы четко понимаете каждую строку vba)))
но переносить vba 1 к 1 в 1с - это нехорошо...
зы:
как я понимаю - Вы уже это сделали, раз решили проблему с метками.
тогда хотя бы оформите это внешней обработкой и пообещайте себе переписать при случае))
(9)
я понимаю, что вариант с excel-ем быстрый, однако для моей задачи он не подходит по ряду причин к примеру:
- необходима лицензия exсel, как собственно и сам exсel
- могут быть проблемы из за версии exсel
- и главное если 2 пользователя одновременно обратятся к 1 расчетному файлу будет "не очень хорошо"
делать все расчеты не на сервере а на пк пользователя конечно выход, однако если пользователей будет хотя бы 20 встанет проблемой каждому закинуть этот файл. + сразу 1 и 2 проблемы станут очень актуальными.
саму метку надо писать вот так: ~имяМетки
тильда в начале обязательна.
ПС:
ах, не заметил - раньше уже ответили. Ну раз в жизни бывают моменты нужды использования метки.
Если нельзя, но сильно хочется, то можно...
Включить голову, и понимать последствия действий. Можно в некоторых случаях и код в более читаемый вид привести, и изподвыперда вылезти - бывают исключения, что с Goto реализуется, а по другому уж очень заморочено. Этот вопрос поднимался уже с 90-х, тут все зависит от случая и метода его реализации.
Приведу пример хорошего, имхо, использования меток (GoTo), которым сам бывает пользуюсь.
Если коротко: использую GoTo для выхода из процедуры из многих точек этой процедуры с выполнением на выходе определенного блока операций.
Скажете, я плохой прогер из-за этого? )
Процедура ПроверкаКоеЧего(пОбъект_, пРежимЗаписи_ = неопределено, пОтказ_ = ЛОЖЬ) Экспорт
лСообщениеПроверки = "";
//В процедуре идет куча различных проверок. Для схематичности показал их здесь как вызов процедур,
//на самом деле каждая проверка оформляется своим блоком "Если", и внутри каждого блока заполняется сообщение-диагностика + прыг на выход из процедуры.
если НЕ Проверка1Пройдена() тогда лСообщениеПроверки = "Ошибка 1201. Не прошла Проверка1."; Перейти ~M99; конецЕсли;
если НЕ Проверка2Пройдена() тогда лСообщениеПроверки = "Ошибка 1202. Не прошла Проверка2."; Перейти ~M99; конецЕсли;
//...
если НЕ Проверка99Пройдена() тогда лСообщениеПроверки = "Ошибка 1299. Не прошла Проверка3."; Перейти ~M99; конецЕсли;
//Еще различные другие действия кроме проверки...
~M99:
если лСообщениеПроверки <> "" тогда
Сообщить(лСообщениеПроверки, СтатусСообщения.Внимание);
пОтказ_ = ИСТИНА;
конецЕсли;
КонецПроцедуры
(13) если программа оптимально выполняет те требования, для которых она написана, какая разница, как она написана. В конце-концов, врачей за плохой почерк критикуют, но лечиться то к ним ходят, несмотря на их почерк. А говорить, что плохой программист, потому что безусловный переход использует? ИМХО в корне неверно.
Лечиться раньше к "бабкам" ходили, на востоке - к "ламам, а сейчас анаферон жрут, в котором, как показали исследования на месс-спектрометре кроме сахаров ничего нет. К врачам только уже при серьезных симптомах идут, часто поздно, да и врачи не реже диагноз неверный ставят (консилиум китайских врачей, которых и расстрелять могут, угадывает диагноз по симптомам в 66% случаев, в то время как ИИ - в 83%).
(14) Сильно зависит от продукта. Если продукт является самодостаточной окаменелостью - то пусть он хоть в машинных кодах писался.
Но чем динамичнее его доработка и сопровождение - тем важнее КАК он написан.
И в 1С второе гораздо чаще первого.
(22) Не очень понял комментария. В БСП, кстати, вполне следят за качеством кода. Большинство рефакторингов БСП, которые я наблюдал, делали код качественнее. Другое дело, что БСП получается "вечной альфой". Они плюют на обратную совместимость внешнего API. Хочешь написать универсальную обработку - не используй БСП.
(23) БСП, по мнению многих неназванных героев, - очень сложная штука. И действительно маразм переиспользования и дейкстровской арийской чистоты кода приводит к стеку вызовов размером с оборотно-сальдовую ведомость средней руки предприятия. Тут уже GO TO с моей точки зрения лучше, чем вся эта спагетти-связанность бесконечного числа бесполезных модулей, функции и процедуры которых мигрируют от версии к версии, что весьма дурно сказывается на поддержке решений, БСП использующих.
БСП, по мнению многих неназванных героев, - очень сложная штука. И действительно маразм переиспользования и дейкстровской арийской чистоты кода приводит к стеку вызовов размером с оборотно-сальдовую ведомость средней руки предприятия.
Это удел любого хорошего, но развесистого фреймворка. Странно на это сетовать.
Это не "сетование", это скорее аргументация супротив Вашего: "И в 1С второе гораздо чаще первого."
Я не принимаю это как аргумент. С чего это сложность кода должна автоматически приниматься как аргумент в сторону его "некачественности"?
Напишите все то же самое проще и тогда будет о чем поговорить.
Включая обсуждение того, какое из двух решений будет проще развивать.
А я не про качественность, а про простоту поддержки.
В "моем мире" это почти одно и то же.
Качественный код отличают две вещи - эффективность и "поддерживаемость" (читабельность и модифицируемость).
Я не хочу ввязываться в спор, что якобы БСП можно было написать лучше. Но лично мне кажется, что большинство людей, сетующих на сложность БСП, просто сравнивают теплое с мягким.
Но лично мне кажется, что большинство людей, сетующих на сложность БСП, просто сравнивают теплое с мягким.
Ну вот от ГОТО перешли к БСП, но по мне ГОТО не так страшен, как страшна БСП, в которой спагетти-кода и безо всякого ГОТО хватает. И поддерживаемость кода с ГОТО (при правильном его применении для выхода из вложенных циклов, например) лучше, чем кода с дополнительными переменными, реализующими подобный функционал без ГОТО.
(13) Я считаю наоборот, если программист сильный и уверен в себе, то не будет спрашивать, что можно использовать, а что нет. В крайнем случае можно замерить производительность, если на то пошло. А слабый как раз будет оглядываться что можно, что нельзя. Обо нет абсолютной истины, все относительно в нашем мире и даже код.
Для таких категоричных выводов информации маловато :)
Но данный пример неудачен. Он слишком легко переписывается на более читабельный без Перейти.
ЗЫ. Ну еще вкусовщина, конечно, но я не одобряю венгерскую нотацию даже в таких лайтовых и понятных вариантах. Люблю, чтобы код читался как проза и глаз не спотыкался. Кстати, не все знают, что редактор модулей легко настраивается на подсветку всех вхождений текущего операнда. Это снимает очень много проблем при анализе чужого или подзабытого кода. Ума не приложу, почему эта настройка не сделана дефолтовой, как в большинстве IDE. Кстати, а что означает нижнее подчеркивание в твоем стайлгайде?
Нет, но это реализуется в данном случае иначе:
1. лСообщениеПроверки = "ххх" заменяется на функцию, включающую то самое после метки.
2. GO TO заменяется на возврат.
Процедура ПроверкаКоеЧего(пОбъект_, пРежимЗаписи_ = неопределено, пОтказ_ = ЛОЖЬ) Экспорт
лСообщениеПроверки = "";
//В процедуре идет куча различных проверок. Для схематичности показал их здесь как вызов процедур,
//на самом деле каждая проверка оформляется своим блоком "Если", и внутри каждого блока заполняется сообщение-диагностика + прыг на выход из процедуры.
если НЕ Проверка1Пройдена() тогда лСообщениеПроверки = "Ошибка 1201. Не прошла Проверка1.";
иначеесли НЕ Проверка2Пройдена() тогда лСообщениеПроверки = "Ошибка 1202. Не прошла Проверка2.";
//...
иначеесли НЕ Проверка99Пройдена() тогда лСообщениеПроверки = "Ошибка 1299. Не прошла Проверка3."; конецЕсли;
//Еще различные другие действия кроме проверки...
если лСообщениеПроверки <> "" тогда
Сообщить(лСообщениеПроверки, СтатусСообщения.Внимание);
пОтказ_ = ИСТИНА;
конецЕсли;
КонецПроцедуры
Процедура ПроверкаКоеЧего(пОбъект_, пРежимЗаписи_ = неопределено, пОтказ_ = ЛОЖЬ) Экспорт
Если НЕ Проверка1Пройдена() Тогда
СказатьЗаОшибку("Ошибка 1201. Не прошла Проверка1.", пОтказ_);
КонецЕсли;
Если НЕ Проверка2Пройдена() Тогда
СказатьЗаОшибку("Ошибка 1202. Не прошла Проверка1.", пОтказ_);
КонецЕсли;
//...
Если НЕ Проверка99Пройдена() Тогда
СказатьЗаОшибку("Ошибка 1299. Не прошла Проверка1.", пОтказ_);
КонецЕсли;
Если НЕ пОтказ_ Тогда
Сообщить("Ну ваще всё круто");
КонецЕсли;
КонецПроцедуры
Процедура СказатьЗаОшибку(Текст, Флаг)
Сообщить(Текст, СтатусСообщения.Внимание);
Флаг = ИСТИНА;
КонецПроцедуры
(34) По условию человек говорит, что после первой же проверки остальные не делаются. И именно поэтому нужен GOTO в самый конец процедуры, чтобы там сообщить.
Это бесконечный спор) И, на самом деле, тут только вопрос архитектуры.
Мне только один раз пришлось пользоваться оператором именно во вложенных циклах, как писал коллега выше. Но только из-за того, что поступили новые требования, когда все уже было написано. Потом этот кусок был переписан целиком.