Знач убирать не стоит, т.к. какой то вызов мог передавать в этот метод свою переменную со значением Неопределено. Тогда ты изменишь ее в месте вызова - она уже станет там неожиданно структурой.
Знач имеет смысл поставить, если метод серверный, но вызывается с клиента, тогда после завершения серверного метода будет меньше данных передаваться на клиент
Продолжу свои нападки :). По поводу метода «Обработать очередь сообщение», что плохо, когда метод и обрабатывает данные и возвращает («методы должны либо обрабатывать либо возвращать»). Во-первых, возвращение данных - это вообще не задача. Задача может быть на чтение данных, на создание или изменение. Просто иногда после создания или изменения данных нужно получить результат этой работы: иногда иноформация об успешности выполнения, иногда сами созданные/измененные данные. И это не просто нормально, а совершенно естественно, когда функция создает и возвращает созданное. Опять же, перейдем в реальную жизнь: человеку можно сказать «купи в магазине хлеб», подразумевая, что он должен купить хлеб и принести (вернуть результат), а можно сказать «оплати в магазине хлеб», а потом сказать «возьми оплаченный хлеб и принеси домой».
Мне очень нравится твой стиль 👍 Те это не говнаревый стиль, а прям дискуссия классная 👍 Возвращение данных это одна из задач. Как раз для этого функции придумали. Второй сценарий с хлебом предпочтительнее. Хотя и может казаться усложнённым.
В разработке на англ. в других языках программирования нормальным считаются функции “get… “. Почему же «Получить» не подходит? Если фактически это есть «получение» когда мы говорим о функциях
Потому что на 1С:ИТС, в разделе "1С:Предприятие 8. Система стандартов и методик разработки конфигураций", написано требование: "Имена процедур, функций и формальных параметров следует образовывать от терминов предметной области таким образом, чтобы из имени было понятно назначение. Следует стремиться к тому, чтобы имена были "говорящими" (документировали сами себя)". Поэтому "Выполнить" или "Получить", использовать не желательно.
@@k33alexey имена функций должны быть очень краткими, и информативными, приписывать постоянно "получить", вообще не зачем, так будет тысячу и одна функция именем получить, оно будет забивать глаза. Можно конечно взять и "получить" написать в конце, ну вместо "ПолучитьБлаБла", написать "БлаБлаПолучить", но не вижу в этом какой-то смысл. Главное в названии понятность, что это за функция, к чему она.
@@yellow_club извините, это не серьезно. Мне 09.01 у CTO согласовывать годовой бюджет на обучение коллег. Когда спросят что/зачем, мне тоже ему сказать "заполняй анкету и все узнаешь"?
@@yellow_club с чего это вдруг? Не пишите ерунды. В любой компании дадут список стандартов и укажут на ошибки, на которые ты и сделаешь поправки своего кода, проще говоря попросят писать так как они там привыкли. Вот и все, расходимся.
@@yellow_clubЯ знал людей с 250К в месяц и срать они хотели на стандарты и на все новое, что появилось после того, как они научились говнокодить в 1С. Они не признают не HTTP сервисы, ни JSON, ни асинхронщину и т.д. Просто проработали уже 10 лет в компании и считают, что достойны именно такой зарплаты. Ведь в 1С знания - ничто, тебя судят по времени, которое ты отработал. Бред, но так и есть. Новичку, что бы он там не знал, и 40 нормально, деду в 1С, пусть он не освежал свои знания уже лет 10, меньше 200 как-то стыдно платить 😂 Именно поэтому сбежал из той конторы. Работу выполняешь одну и ту же, но коллега получает за нее в 5-6 раз больше просто потому, что он уже лет 10 отработал, а ты всего год.
Понимаю, что стандарты 1С - это святое… Но вот есть допустим две функции: получить данные из такой-то базы, и записать данные из такой-то базы. Первая просто получает данные и возвращает, допустим структуру. Вторая внутри себя вызывает первую и записывает в РС, а возвращает какую-то информацию, например что удалось и не удалось записать. Если убрать глаголы, то придется поизвращаться с наименованиями этих функций, хотя с глаголами все четко и понятно
Вот это требование «не использовать Получить», потому что везде будете использовать, а лучше «забрать», «запросить» - по-моему довольно странное требование. Представляю картину из реальной жизни: курьеру говорят «отнеси пакет туда-то», «теперь отнеси эту коробку туда-то», «отнеси конверт туда-то» и т.д. И тут волшебный эйчар делает замечание: «хватит говорить «отнеси», вы ведь все время так говорите, ну скажите «перенеси», «доставь», «перемести», ну «закинь» в конце концов». Можно еще 1с-никам претензию высказать, чтобы вместо слова «Процедура» можно было написать «Метод»,«Просиджа», «Делалка», «Запускалка» и т.д. Даешь разнообразие!
Речь не об этом. В именах функций глаголы используются в определенных ситуация, обычно глаголы в именах функций не нужны и только усложняют понимание кода
@@yellow_club Насчет усложнения кода (ухудшения читабельности) - это очень субъективно. Во-первых, если не внушать себе что «получить» в названии функции - это плохо, то это не бросается в глаза. Во-вторых, программисты именно потому и пишут «получить», что для них такой код более комфортен для чтения. В третьих, большинство методов - это все же процедуры, а не функции, поэтому как правило в коде нечасто можно встретить более одного вызова функции с префиксом «Получить» (есть ведь еще «Проверить», «Это» и т.д.). Чем ближе программный код к человеческой речи, тем легче читается. Кстати в типовых конфигурациях от 1С регулярно встречаются функции «получить».
@CuriousAlehandro у тебя может быть такое мнение и это нормально. Я исхожу из опыта людей, которые с 60-70 годов пишут код. Подозреваю, что они не зря это рекомендуют.
Выгружать результат запроса в таблицу значений и далее работать с ней, что бы не дергать базу повторным запросом. Этот вариант будет не оптимален, если выборка будет 100К+ записей, но в случае с телегой, такое количество сообщений в очереди маловероятно. Вообще, использование справочника, а не РС для хранения очереди сообщений выгляди странно, РС будет работать заметно быстрее. Так же в коде проскакивало "НайтиПоКоду" - лютый моветон.
вы не видите реальности, вы даже не знаете потребностей, чёт там себе решаете, а реальных клиентов в глаза не видели. И это проблема - начиная с Чистова, который ставит задачи под самых умных в пбу, где нет компаний, и и если они есть, то там главбухи умнее Чистова на порядок, и заканчивая вашими решениями которые нафиг никому не нужны @@yellow_club
22:43 Двухсотый код состояния - стандартный ответ успешного хттп-запроса. Всё тут нормально с ответственностью, имхо. Не надо обработку кодов поднимать на уровень бизнес-логики.
Приветствую ребят. Хотел спросить, мне 16 лет и я учусь в 9 классе, думаю уходить после 11 класса, сдаю физику и информатику, буквально недавно у нас по информатике , у нас был впервые урок про программирование , а именно про язык программирования Phyton. И такой вопрос, что мне делать, на данный момент когда такая ситуация, что можете предложить, как будущему программисту ?
Какой смысл телеграм -ботов писать на 1С, если есть нормальные типизированные языки - джава, котлин, тайп скрипт? С возможностями на два порядка больше чем в 1С?
@@yellow_clubХочу ещё добавить: для того, чтобы твое лицо не становилось похоже на известную картину 😱, когда заказчик просит сделать серьезную доработку
