Процедура або функція
Уявімо, що ми пишемо якийсь код, в якому можуть бути використані як процедури, так і функції. Код містить ділянки, в яких можуть статися помилки, і ділянки, в який помилок ми не очікуємо. Вкладеність викликів може бути довільною. У той же самий час хочеться легким способом отримати діагностику помилково настільки докладної, щоб все ланцюжка викликів були "як на долоні".
Виходячи з цих міркувань і виникає бажання визначити чіткі критерії того, в якому випадку варто використовувати Процедури, а в якому разі Функції.
Невелике опитування серед своїх товаришів по службі виявив кілька різних підходів до цієї проблеми.
Але з позитивних зауважень вийшло виділити кілька ідей.
Підхід 1. Виходячи з визначення Процедури і Функції
Тут все просто, Новомосковскешь документацію і, пам'ятаючи, що процедура відрізняється від функції тільки повертається значенням, вирішуєш - якщо повернення значення не потрібен, то Процедура, якщо потрібен, то Функція. Проте, процедура може змінювати значення параметрів, переданих по Посиланням.
У контексті даного підходу, є два розгалуження на тему, як фукнции повинна повертати параметри:
Підхід 1.1 Функція повертає один параметр через повернення, інші через змінні, передані по посиланню. На виході процедури ми включаємо якусь обробку помилок, що залежить від значення, що повертається.
Підхід 1.2 Функція не може повертати значення через свої параметри і повинна це робити тільки через значення повернення. Якщо необхідно повернути більше одного значення, то ці значення необхідно упакувати в масив, список значень, інше.
Якщо в ході роботи з'явилася помилка, то буде повернуто значення Не визначено.
Підхід 2. Процедури - вони як макроси
При цьому підході Процедура використовується всього лише для того, щоб об'єднати кілька викликів однотипних дій.
У цьому підході використання Процедури носить локальний характер - просто для того, щоб скоротити код.
Підхід 3. Все на світі - Функції, але без ідіотизму
1. Завжди використовуються функції, процедури не використовуються.
2. Функція повертає або "", або строкове опис помилки, всі зміни даних йдуть по посиланню через вихідні параметри
3. Для виключення ідіотизму в застосуванні правила 2, для функцій, які повертають гарантовано одне значення, без помилок усередині функції, використовується передача значення через повернення функції. Наприклад, ЕтоКорректнаяДата (вхДата)
Ось поки що вийшло. А які є підходи у вас?
8. brix8x (brix8x) 469 21.01.08 9:46 Зараз в темі
Я в своїй роботі використовую підхід "Все на світі функції".
Це зручно, коли йдуть вкладені функції і ти можеш отримати весь ланцюжок цих викликів.
Якщо ПОМИЛКА Тоді Повернення імяФункціі + ": Нормальне тестове опис помилки";
Повернення ""; // якщо все добре
КонецФункціі
Функція Зовнішня (вхПар1, вхПар2, вихПар1) // Зовнішня, але не інтерфейсна функція
//<Блок ошибок выполнения
Перем рез;
Перем імяФункціі;
імяФункціі = "Зовнішня";
/>
рез = суперВнутр (вхПар1, вхПар2, вихПар3);
Якщо Чи не ПустаяСтрока (рез) Тоді Повернення імяФункціі + ": Опис помилки для Зовнішня";
Повернення ""; // якщо все добре
КонецФункціі
Процедура ОбработчкікСобитія1С (Відмова) // процедура - показник обробника 1С
Перем Пар1, Пар2, Пар3;
Перем рез;
рез = ВнешняяНоНеІнтерфейсная (Пар1, Пар2, Пар3);
Якщо Чи не ПустаяСтрока (рез) Тоді
СообщітьОбОшібке (рез, Відмова); повернення;
КонецЕсли;
У разі помилки ми отримуємо щось на кшталт: "Зовнішня: Опис помилки для Зовнішня: суперВнутр: Опис помилки для суперВнутр"
================================================== ========== ====
Захист від ідіотизму полягає в тому, що функції, які повертають логічне і не можуть (теоретично) призвести до помилки можна використовувати звичним способом, наприклад, ЕтоКорректнаяДата (вхДата).
Маючи такий набір правил, я можу створити шаблон і зробити його стандартом і, в майбутньому, перевірити дотримання цього стандарту.
Цей підхід прекрасно працює і на VB, і на VBSctipt. Я б і далі використовував цей підхід, але він дав "збій" на мові Jcript :-(. До функцій на JScript можна передати по посиланню змінні звичайного типу (число, дата), таким чином якщо всередині фукнции змінюється кілька змінних звичайного типу , я не зможу працювати в тому, стилі, який тільки що описав.
Саме через це і народився цей пост. Як бажання побачити інші підходи, опрацьовані досить глибоко, щоб їх потім можна було відобразити в набір простих правил для "зелених" студентів.
Поки ж на JScripte я пишу як повна мавпа - за настроєм. Ж - (((
Схиляюся до думки, що або доведеться відмовитися від JScript, або для нього придумати інший стиль.
Є стиль, який можна спробувати адаптувати:
1. Все на світі функції, але повертаються значення тільки через Повернення
2. Якщо їх багато, що через повертається масив
3. Якщо є помилка, то перший елемент масиву - не визначено, а другий - текстовий опис помилки.
Але тут я знову повертаюся до "старої натоптаний доріжці", може чого не бачу?