9 порад LabVIEW-програмістам 3


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

  1. Вчіться малювати блок-схеми. Чесно кажучи, сучасні студенти часто не розуміють для чого потрібно вміти малювати графічний алгоритм, дехто навіть не може описати послідовність дій словесно. Та, не маючи чіткого уявлення про те, як повинна працювати програма, братися за її реалізацію не надто далекоглядно. Дехто звик, що технічне завдання на програмний продукт повинен ставити замовник, але досвід показує, що найчастіше замовник може лише в загальних рисах описати, що саме йому потрібно, а далі спроектувати і запропонувати рішення доводиться уже виконавцеві.
  2. Фрагменти програми перевіряйте окремо. Запам’ятати всі нюанси використання того чи іншого вузла здатен далеко не кожен висококласний фахівець. Але знання кількох принципів звільняє від необхідності вивчати тисячі фактів, тож окремі частини програми, у реалізації яких Ви дещо сумніваєтеся, доцільно детальніше розглянути у вигляді окремого мікропроекту. І переносити код до основної програми варто лише тоді, коли відокремлений він працює бездоганно.
  3. Один раз зроби – багато разів використовуй. Окремі більш-менш самостійні ділянки коду варто зберігати в окремих файлах як підпрограми і використовувати їх в інших проектах. Звісно, може статися так, що ці ділянки більше ніколи не знадобляться, але часто дуже багато часу займає саме повторне написання уже колись реалізованих функцій.
  4. Називайте речі своїми іменами. Як сказав колись класик, “програмування – це мистецтво вигадувати нові імена”, тож не варто залишати у своїх проектах стандартні знеособлені назви типу Numeric 3 або Button 1 – зрозуміти для чого використовувався той чи інший елемент трохи згодом буде непросто. Імена функціям, змінним, регуляторам та індикаторам варто давати такі, щоб із самої назви вже було зрозуміло призначення елемента програми. Те ж саме стосується і іменування файлів. Погодьтесь, назва файлу “Untitled 123.vi” мало що говорить про його вміст.
  5. Коментуйте! Така корисна річ як коментарі не даремно присутня у LabVIEW, адже навіть очевидний зараз алгоритм за кілька років може здаватися дещо заплутаним, не кажучи вже про те, що програму, можливо, доведеться підтримувати і переробляти іншій людині. Тому коментування неочевидних частин блок-діаграми, посилання на використані запозичені функції, окремих станів структури Case, циклів з умовою – просто обов’язкове.
  6. Дотримуйтесь порядку. Переважно намагання добитися того, аби блок-діаграма виглядала гарно, сприймається студентами як марна трата часу (іноді навіть як знущання). Та насправді варто привчити себе до порядку у програмі і відшукати помилку і ній стане набагато простіше. У комбінації з попередніми двома порадами це здатне зробити Ваш код зрозумілим для будь-кого.
  7. Групуйте схожі візуальні компоненти. Якщо на лицьовій панелі Вашого віртуального приладу планується наявність великої кількості кнопок та індикаторів, то варто поєднати ті з них, що стосуються якоїсь певної частини, у кластер, або навіть візуально згрупувати за допомогою елементів з палітри Decorations.
  8. Дотримуйтеся розмірів. Хорошим тоном вважається можливість розмістити всю блок-діагарму на одному екрані Вашого монітора, щоб не довелося використовувати прокрутку для її перегляду. Це дає можливість бачити, звідки беруться дані і куди вони потрапляють у результаті виконання програми. Аналогічного правила слід дотримуватися і при проектуванні передньої панелі віртуального приладу. Тільки при цьому варто мати на увазі, що роздільна здатність дисплею ПЕОМ, на якій експлуатуватимуть Ваш проект, може бути меншою, аніж у Вашого ПК. Тому, якщо є така можливість, намагайтеся, щоб передня панель була компактною.
  9. І наостанок запам’ятайте наступну річ: суттєво зекономити час допоможе знання розповсюджених сполучень “гарячих клавіш” та використання контекстного меню “Create”, “Replace”, тощо.

Ось ніби і все. Якщо у когось із досвідчених програмерів є що додати до цих правил – прошу писати у коментарях 🙂

Почитайте ще оце:


Залиште коментар

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

3 thoughts on “9 порад LabVIEW-програмістам

  • Максим

    На блок-діаграмі не користуватись іконками, тоді вона буде значно і значно меншою і відповідно можна буде вмістити більше елементів, бо далеко не завжди можна або доцільно частину коду переробляти в підпрограму.

    • Akceptor Від автора

      Згоден на всі 100. Але помітив, що новачкам буває важко розібратися, коли View as Icon вимкнено 🙁
      На рахунок того, що не завжди доцільно переробляти частину коду на підпрограму теж згоден. У порадах йдеться про те, що треба наперед планувати розробку модульної програми, а не “OMG, блок-діаграма не поміщається на екран! А давайте половину просто у SubVI загорнемо :)”
      PS
      Якщо хочеш і маєш що розповісти про програмування у LabVIEW (власний досвід, враження, перспективи) – з задоволенням опублікую гостьовий допис. Там можеш і лінк на своє портфоліо вписати і т.п.