Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Правила хорошого тону.docx
Скачиваний:
2
Добавлен:
01.03.2025
Размер:
48 Кб
Скачать
☆

Правило #11, дані про

Організація даних у програмі - це питання не менш важливЕ (а іноді, можливо, навіть більше важливий), ніж алгоритмічна структурованість програми. Спеціально для цілей структуризації даних існують чудові типи даних, структури (або запису в термінах мови програмування Паскаль). Якщо Ваша програма працює з якої сутністю, ця сутність, особливо якщо вона складна, ПОВИННА бути описана в програмі за допомогою структури. Складна програма, в якій немає жодного масиву або структури - це ПОГАНА програма.

Правило #12, про умову

Перевіряйте умова на істину, а не навпаки. Правильно: msg = (code == 0) ? "Успіх" : "Помилка"; Невірно: msg = (code != 0) ? "Помилка" : "Успіх"; Чи Не правда перший приклад читається природно і легко, в той час як другий вимагає якогось напруги? Використовувати не рекомендується. Вираження типу: msg = (code == 0 ? "Успіх" : (code == 1 ? "Попередження" : "Помилка")); краще замінити на конструкцію if-else-if або switch-case.

Резюме

Порушення будь-якого з описаних вище правил відразу впадає в очі під час перегляду чужого коду. Чи треба говорити, що не дотримання цього мінімуму формує негативну думку про автора коду. Але важливо не думка оточуючих, а ваша власна ефективність при розробці програм???. Не допускайте вольності. Визначте для себе правила і завжди дотримуйтесь їх. Оформлення програмного коду - це не місце для творчого польоту. Тут все має бути абсолютно одноманітно і стандартизовано (хоча б у рамках однієї програми). Описані вище правила це - вершина айсберга. Для кожного конкретної мови програмування існують окремі нотації, які містять багато корисного, що можна взяти на озброєння, але це - окрема розмова. Поки ж пропоную дотримуватися цих простих рекомендацій завжди і скрізь.

http://edu.mmcs.sfedu.ru/file.php/36/cs_coding_std.pdf

http://www.ce.cctpu.edu.ru/study.php?page=102