- •Правило #0, про коментарі
- •Правило #1, про кількість операторів в рядку
- •1. Кількість операторів на рядку повинно бути дорівнює 1.
- •2. Слово var пишеться на окремому рядку.
- •4. Слова begin і end
- •Правило #2, про горизонтальні відступи
- •1. Намагайтеся помістити функцію в екран
- •2. Використовуйте табуляцію замість пробілів.
- •Правило № 4, про горизонтальні відступи
- •Правило #3, про операторні дужки
- •Правило #5, про вертикальні пробіли (порожні рядки)
- •Правило № 6, про оголошення змінних
- •Правило #7, про що говорять ідентифікатори
- •Правило #8, про ініціалізацію масивів
- •Правило #9, про функції/процедури
- •Правило #10, про помилки та ще дещо про що
- •Правило #11, дані про
- •Правило #12, про умову
Правило #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
