Вікіпедія

Домовленості про стиль коду

Норми кодування (англ. Coding conventions) — це сукупність вказівок, що стосуються певної конкретної мови програмування і встановлюють правила стильового оформлення коду, практики та методи написання програм цією мовою. Ці норми зазвичай охоплюють організацію файлів, відступи, коментарі, оголошення, інструкції, пропуски, норми найменування, практики та принципи програмування, емпіричні правила програмування, найкращі архітектурні практики та ін.. Це поради стосовно структурної якості програмного забезпечення. Розробникам програмного забезпечення наполегливо рекомендується слідувати цим вказівкам, щоб покращити читабельність їхнього коду та полегшити підтримку програмного забезпечення. Норми кодування застосовні лише до людей-підтримувачів та рецензентів програмного забезпечення. Норми можуть бути формалізовані в документованому наборі правил, яких дотримується ціла команда чи компанія, або бути такими ж неформальними, як звичні індивідуальні практики кодування. Норми кодування не нав'язуються компіляторами. А отже, не дотримання деяких, чи навіть всіх правил не впливає на ефективність виконання програмного коду.

Підтримка програмного забезпечення ред.

Зменшення затратності підтримки програмного забезпечення є найбільш поширеною причиною дотримання норм кодування. У своїй передмові до норм програмування мовою Java, Sun Microsystems наводить такі міркування:[1]

Норми кодування важливі для розробників програмного забезпечення з кількох причин:

  • 40 %–80 % загальної вартості програмного забезпечення витрачається на його утримання.[2]
  • Майже ніколи програмне забезпечення не підтримується до самого кінця своїм початковим автором.
  • Норми кодування покращують читабельність програмного забезпечення, дозволяючи розробникам швидше й краще розбиратись в новому коді.
  • Подібно до всякого іншого продукту, програмне забезпечення має бути «добре упакованим» і чистим.

Програмна інженерія ред.

Програмна інженерія це процес розробки змісту та дизайну проєкту. Вона є визначальною в питаннях успіху проєктів, зокрема й великих. Процес програмної інженерії — це те, що доводить процес кодування до успішного завершення. Хороша програмна інженерія задає різницю між проєктами успішним — у фінансовому й технічному розумінні — та такими, що, в найгіршому випадку, перебувають у стані «клінічної смерті». Хороша програмна інженерія зведе до мінімуму подальші витрати і підвищить успіх проєкту на ринку.

Документація проєкту ред.

Згідно з нормами кодування, проєкт повинен містити наступні документи:

  1. Досьє проєкту (англ. The project brief). Процес розробки починається зі створення цього документу. Строго кажучи, це лише короткий опис проєкту, що входить до ланцюга його офіційних документів.
  2. Опис вимог (англ. The requirements specification). В цьому документі вказується, що саме робить проєкт. Він є найважливішим в ланцюгу документів, усі інші документи тісно пов'язані з ним.
  3. Дизайн проєкту (англ. The project design). Це офіційний документ з описом дизайну. Він перелічує модулі й компоненти, описує їх інтерфейси та пояснює зв'язки між ними. Програмний інженер, що працює над цим документом виконує такі завдання:
    • Вибір найкращого варіанту дизайну з наявних опцій на основі їх аналізу.
    • Ананіз всі аспекти, зокрема технічні, комерційні, питання якості, адміністрування й логістики. Це передбачає й час та вартість розробки, утримання, підтримки й використання — як поточні, так і подальші.
  4. Опис тестів (англ. The test specification). Цей документ описує всі тести, які має пройти проєкт, та результати, яких варто чекати від такого тестування. Дуже часто тестування виконується спеціальними програмними пакетами, а отже ці тести описуються відповідними файлами.
  5. Результати тестів (англ. The test results).

Опис проєкту від досьє до результатів тестування становить так званий ланцюг документів. Кожен документ пов'язаний з попереднім відношенням «один до одного». Крім того, опис тестів пов'язаний з описом вимог. Ланцюг документів двонапрямний — опис іде вниз, результати повертаються нагору.

Ці методи називаються формальними.

Рефакторинг ред.

Рефакторинг — це процес зміни існуючого коду для його вдосконанлення та відповідності існуючим домовленостям про стиль коду без зміни його поведінки. Рефакторинг існуючого коду є важливою складовою його підтримки та потенційно переслідує такі цілі:

  1. Вдосконалення дизайну, структури та імплементації програмного забезпечення.
  2. Збільшення читабельності та спрощення сирцевого коду.
  3. Сприяння ефективній підтримці програмного забезпечення — пришвидшення додавання нового функціоналу.
  4. Ефективне використання апаратного забезпечення, збільшення швидкості виконання коду.[джерело?]

Практика норм кодування ред.

Існують декілька підходів до покращення читабельності коду, серед них такі:

  1. Домовленості з найменування змінних, функцій та класів.
  2. Дотримання правил відступів, пробілів та знаків табуляції.
  3. Додавання коментарів в код для сприяння розумінню функціоналу.

Домовленості з найменування ред.

Першочергова ціль правил найменування змінних значно спрощує розуміння сирцевого коду та ролі конкретної змінної. Кожна змінна повинна мати чітку та лаконічну назву, що надає семантики кінцевому коду[3][4].

Вибране правило найменування змінних має бути дотриманим в усьому коді

Різні мови програмування можуть мати різні норми найменування змінних, що дозволяє розрізняти операнди та ключові слова.

В свою чергу, найменування змінних підрозділяються на такі варіанти:

Зміїний регістр ред.

Докладніше: Зміїний регістр

У формі нотації "зміїний регістр" (англ. Snake case) використовується знак підкреслення для виділення окремих слів в назві змінної:

var_one

var_two

регістр Паскаля ред.

Регістр Паскаля (англ. Pascal case) передбачає виділення окремих слів за рахунок перших букв кожного з них в верхньому регістрі:

VarOne

VarTwo

Верблюжий регістр ред.

Докладніше: Верблюдячий регістр

Верблюжий регістр (англ. Camel case) повторює Pascalcase - кожне слово виділяєтья першою буквою у верхньому регістрі за винятком першої букви:

varOne

varTwo

Шашличний регістр ред.

Докладніше: Шашличний регістр

Шашличний регістр (англ. kebab case) повторює підхід зміїного регістру з розділенням слів в найменуванні знаками пунктуаціями, для цього використовуються знаки тире (dash, '-'):

var-one

var-two

Угорська нотація ред.

Докладніше: Угорська нотація

В Hungarian Notation (Угорській нотації) виділяється перше слово найменування, що визначає тип змінної, а решта слів визначає її функцію. Приклад такої нотації в Camel case:

arrExpVarOne // букв. "масив, приклад змінної 1"

intExpVarTwo // букв. "ціле число, приклад змінної 2"

All caps[5]

All caps (All capitals, всі великі) має всі літери в верхньому регістрі та застосовується для позначення констант у коді:

CONST_ONE

CONST_TWO

Примітки ред.

  1. ↑ Code Conventions for the Java Programming Language : Why Have Code Conventions. Sun Microsystems, Inc. 20 квітня 1999. Архів оригіналу за 24 вересня 2015. Процитовано 12 вересня 2015.
  2. ↑ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
  3. ↑ Coding best practices — Research Computing University of Colorado Boulder documentation. curc.readthedocs.io. Процитовано 16 лютого 2024.
  4. ↑ Snake Case VS Camel Case VS Pascal Case VS Kebab Case – What's the Difference Between Casings?. freeCodeCamp.org (англ.). 29 листопада 2022. Процитовано 16 лютого 2024.
  5. ↑ Guidelines for naming variables, subroutines, and scripts. www.ibm.com (англ.). 12 січня 2022. Процитовано 16 лютого 2024.

Посилання ред.

Норми кодування для мов ред.

Норми кодування для проєктів ред.

  Ця стаття є заготовкою. Ви можете допомогти проєкту, доробивши її. Це повідомлення варто замінити точнішим.
Отримано з https://uk.wikipedia.org/w/index.php?title=Домовленості_про_стиль_коду&oldid=41831399