Приклад:

Робота з розшифровкою в керованому застосунку

У цій статті описується, як працювати з розшифровкою звіту, створеного за допомогою системи компонування даних, у керованому застосунку.

Робота з параметром «Відмова» в обробниках подій

1. В обробниках подій модулів об'єктів, наборів записів, форм тощо, що містять параметр Відмова (ПриЗаписи, ОбработкаПроверкиЗаполнения, ТоварыПередНачаломДобавления тощо), не слід надавати цьому параметру значення Ложь.Ця вимога зумовлена тим, що, як правило, у коді обробників подій параметр Відмова може встановлюватися одразу в кількох послідовних перевірках (або в кількох підписках на одну й ту саму подію). У такому разі до моменту виконання чергової перевірки параметр Відмова вже може заздалегідь містити значення Истина, і його можна помилково скинути назад у Ложь.Крім того, під час доопрацювань конфігурації на впровадженні кількість цих перевірок може збільшитися.

Опис процедур і функцій

1. Опис процедур і функцій рекомендується виконувати у вигляді коментаря до них. Необхідність коментування окремих ділянок коду процедур і функцій має визначатися розробником, виходячи зі складності та нестандартності конкретної ділянки коду.Автовпорядкування коментарів до процедур або функцій із директивами компіляції

Взаємопов’язані поля

Реквізит Посилання в динамічних списках

Використовуючи можливості керованих форм, користувач може додати відображення будь-яких реквізитів об'єктів у динамічному списку. Для того щоб користувач міг скористатися цією можливістю, рекомендується додавати до списку поле Посилання, у якого потрібно вимикати користувацьку видимість.

Перенесення виразів

1. Якщо довжина рядка перевищує 120 символів, слід використовувати перенесення. Робити рядки довшими за 120 символів не рекомендується, за винятком випадків, коли перенесення неможливе.

Видалення застарілих об'єктів метаданих із конфігурації

1. Якщо під час зміни структури метаданих конфігурації планується видалити об'єкт метаданих (реквізит, вимір, ресурс тощо), пов'язаний із записами інформаційної бази, то необхідно прийняти рішення про видалення або перенесення даних цього об'єкта в нові структури. Під час перенесення даних до інших об'єктів рекомендується дотримуватися таких правил:

Попередня ініціалізація локальних змінних

У випадках, коли фрагмент коду обчислює значення однієї або кількох локальних змінних, рекомендується явно виконувати попередню ініціалізацію таких змінних. Це дасть змогу уникнути потенційних помилок часу виконання, коли значення змінної виявляється Невизначено, а подальший код розраховує на певний тип значення. Наприклад:

Оформлення елементів

Назви одних і тих самих об'єктів, їх розташування мають бути однаковими для всіх форм. Приклад: Номер, дата документа, клієнт/постачальник, контрагент, угода завжди знаходяться в одному й тому самому місці, незалежно від документа.

Розробка планів обміну з відборами

1.1. Як правило, для синхронізації даних між різними конфігураціями та для організації розподіленої інформаційної бази (РІБ) використовується технологія планів обміну. У цьому випадку часто виникає завдання організації обміну не всіма даними інформаційної бази, а лише частиною даних. Наприклад, дані можуть бути відібрані для надсилання до інших вузлів у розрізі організацій, складів, підрозділів тощо.

Отримання метаданих об'єктів

1. У тих випадках, коли відомий тип об'єкта метаданих (довідник, документ тощо), отримання метаданих об'єкта конфігурації слід виконувати за допомогою методу Метадані цього об'єкта (або посилання для об'єктів посилального типу), а не шляхом звернення до властивості глобального контексту Метадані, оскільки другий спосіб істотно повільніший. Правильно:

Правила утворення імен змінних

1. Імена змінних слід утворювати від термінів предметної області таким чином, щоб з імені змінної було зрозуміло її призначення. 2. Імена слід утворювати шляхом видалення пробілів між словами. При цьому кожне слово в імені пишеться з великої літери. Прийменники та займенники з однієї літери також пишуться з великої літери. Приклад:Див. також