Домовленості про стиль коду
Норми кодування (англ. Coding conventions) — це сукупність вказівок, що стосуються певної конкретної мови програмування і встановлюють правила стильового оформлення коду, практики та методи написання програм цією мовою. Ці норми зазвичай охоплюють організацію файлів, відступи, коментарі, оголошення, інструкції, пропуски, норми найменування, практики та принципи програмування, емпіричні правила програмування, найкращі архітектурні практики та ін.. Це поради стосовно структурної якості програмного забезпечення. Розробникам програмного забезпечення наполегливо рекомендується слідувати цим вказівкам, щоб покращити читабельність їхнього коду та полегшити підтримку програмного забезпечення. Норми кодування застосовні лише до людей-підтримувачів та рецензентів програмного забезпечення. Норми можуть бути формалізовані в документованому наборі правил, яких дотримується ціла команда чи компанія, або бути такими ж неформальними, як звичні індивідуальні практики кодування. Норми кодування не нав'язуються компіляторами. А отже, не дотримання деяких, чи навіть всіх правил не впливає на ефективність виконання програмного коду.
Зменшення затратності підтримки програмного забезпечення є найбільш поширеною причиною дотримання норм кодування. У своїй передмові до норм програмування мовою Java, Sun Microsystems наводить такі міркування:[1]
Норми кодування важливі для розробників програмного забезпечення з кількох причин:
- 40 %–80 % загальної вартості програмного забезпечення витрачається на його утримання.[2]
- Майже ніколи програмне забезпечення не підтримується до самого кінця своїм початковим автором.
- Норми кодування покращують читабельність програмного забезпечення, дозволяючи розробникам швидше й краще розбиратись в новому коді.
- Подібно до всякого іншого продукту, програмне забезпечення має бути «добре упакованим» і чистим.
Програмна інженерія це процес розробки змісту та дизайну проєкту. Вона є визначальною в питаннях успіху проєктів, зокрема й великих. Процес програмної інженерії — це те, що доводить процес кодування до успішного завершення. Хороша програмна інженерія задає різницю між проєктами успішним — у фінансовому й технічному розумінні — та такими, що, в найгіршому випадку, перебувають у стані «клінічної смерті». Хороша програмна інженерія зведе до мінімуму подальші витрати і підвищить успіх проєкту на ринку.
Згідно з нормами кодування, проєкт повинен містити наступні документи:
- Досьє проєкту (англ. The project brief). Процес розробки починається зі створення цього документу. Строго кажучи, це лише короткий опис проєкту, що входить до ланцюга його офіційних документів.
- Опис вимог (англ. The requirements specification). В цьому документі вказується, що саме робить проєкт. Він є найважливішим в ланцюгу документів, усі інші документи тісно пов'язані з ним.
- Дизайн проєкту (англ. The project design). Це офіційний документ з описом дизайну. Він перелічує модулі й компоненти, описує їх інтерфейси та пояснює зв'язки між ними. Програмний інженер, що працює над цим документом виконує такі завдання:
- Вибір найкращого варіанту дизайну з наявних опцій на основі їх аналізу.
- Ананіз всі аспекти, зокрема технічні, комерційні, питання якості, адміністрування й логістики. Це передбачає й час та вартість розробки, утримання, підтримки й використання — як поточні, так і подальші.
- Опис тестів (англ. The test specification). Цей документ описує всі тести, які має пройти проєкт, та результати, яких варто чекати від такого тестування. Дуже часто тестування виконується спеціальними програмними пакетами, а отже ці тести описуються відповідними файлами.
- Результати тестів (англ. The test results).
Опис проєкту від досьє до результатів тестування становить так званий ланцюг документів. Кожен документ пов'язаний з попереднім відношенням «один до одного». Крім того, опис тестів пов'язаний з описом вимог. Ланцюг документів двонапрямний — опис іде вниз, результати повертаються нагору.
Ці методи називаються формальними.
Рефакторинг — це процес зміни існуючого коду для його вдосконанлення та відповідності існуючим домовленостям про стиль коду без зміни його поведінки. Рефакторинг існуючого коду є важливою складовою його підтримки та потенційно переслідує такі цілі:
- Вдосконалення дизайну, структури та імплементації програмного забезпечення.
- Збільшення читабельності та спрощення сирцевого коду.
- Сприяння ефективній підтримці програмного забезпечення — пришвидшення додавання нового функціоналу.
- Ефективне використання апаратного забезпечення, збільшення швидкості виконання коду.[джерело?]
Існують декілька підходів до покращення читабельності коду, серед них такі:
- Домовленості з найменування змінних, функцій та класів.
- Дотримання правил відступів, пробілів та знаків табуляції.
- Додавання коментарів в код для сприяння розумінню функціоналу.
Першочергова ціль правил найменування змінних значно спрощує розуміння сирцевого коду та ролі конкретної змінної. Кожна змінна повинна мати чітку та лаконічну назву, що надає семантики кінцевому коду[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
- ↑ Code Conventions for the Java Programming Language : Why Have Code Conventions. Sun Microsystems, Inc. 20 квітня 1999. Архів оригіналу за 24 вересня 2015. Процитовано 12 вересня 2015.
- ↑ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
- ↑ Coding best practices — Research Computing University of Colorado Boulder documentation. curc.readthedocs.io. Процитовано 16 лютого 2024.
- ↑ Snake Case VS Camel Case VS Pascal Case VS Kebab Case – What's the Difference Between Casings?. freeCodeCamp.org (англ.). 29 листопада 2022. Процитовано 16 лютого 2024.
- ↑ Guidelines for naming variables, subroutines, and scripts. www.ibm.com (англ.). 12 січня 2022. Процитовано 16 лютого 2024.
- ActionScript: Flex SDK coding conventions and best practices
- Ada: Ada 95 Quality and Style Guide: Guidelines for Professional Programmers [Архівовано 12 грудня 2010 у Wayback Machine.]
- Ada: Guide for the use of the Ada programming language in high integrity systems[недоступне посилання з квітня 2019] (ISO/IEC TR 15942:2000)
- Ada: NASA Flight Software Branch — Ada Coding Standard
- Ada: European Space Agency's Ada Coding Standard[недоступне посилання з квітня 2019] (BSSC(98)3)
- C: Ganssle Group's Firmware Development Standard [Архівовано 22 вересня 2015 у Wayback Machine.]
- C: Netrino Embedded C Coding Standard [Архівовано 3 липня 2011 у Wayback Machine.]
- C: Install Java On Windows
- C++: Quantum Leaps C/C++ Coding Standard [Архівовано 24 вересня 2015 у Wayback Machine.]
- C++: C++ Programming/Programming Languages/C++/Code/Style Conventions
- C++: GeoSoft's C++ Programming Style Guidelines [Архівовано 27 серпня 2011 у WebCite]
- C++: Google's C++ Style Guide
- C++: High Integrity C++
- C#: C# Coding Conventions (C# Programming Guide) [Архівовано 17 серпня 2015 у Wayback Machine.]
- C#: Design Guidelines for Developing Class Libraries [Архівовано 1 березня 2015 у Wayback Machine.]
- C#: Brad Abrams [Архівовано 16 березня 2010 у Wayback Machine.]
- C#: Philips Healthcare [Архівовано 5 липня 2008 у Wayback Machine.]
- D: The D Style [Архівовано 23 вересня 2015 у Wayback Machine.]
- Dart: The Dart Style Guide [Архівовано 3 липня 2015 у Wayback Machine.]
- Erlang: Erlang Programming Rules and Conventions [Архівовано 4 вересня 2010 у Wayback Machine.]
- Flex: Code conventions for the Flex SDK [Архівовано 8 серпня 2015 у Wayback Machine.]
- Java: Ambysoft's Coding Standards for Java [Архівовано 20 серпня 2020 у Wayback Machine.]
- Java: Code Conventions for the Java Programming Language [Архівовано 24 вересня 2015 у Wayback Machine.]
- Java: GeoSoft's Java Programming Style Guidelines [Архівовано 15 вересня 2015 у Wayback Machine.]
- Java: Java Coding Standards, каталог посилань Open Directory Project
- Java: SoftwareMonkey's Coding Standards for Java and other C-like languages[недоступне посилання з липня 2019]
- JavaScript: Code Conventions for the JavaScript Programming Language [Архівовано 5 березня 2012 у Wayback Machine.]
- Lisp: Riastradh's Lisp Style Rules [Архівовано 2 жовтня 2015 у Wayback Machine.]
- MATLAB: Neurobat Coding Conventions for MATLAB [Архівовано 14 жовтня 2014 у Wayback Machine.]
- Mono: Programming style for Mono [Архівовано 23 вересня 2015 у Wayback Machine.]
- Object Pascal: Object Pascal Style Guide [Архівовано 9 липня 2015 у Wayback Machine.]
- Perl: Perl Style Guide [Архівовано 26 червня 2013 у Wayback Machine.]
- PHP::PEAR: PHP::PEAR Coding Standards [Архівовано 10 березня 2017 у Wayback Machine.]
- PHP::FIG: PHP Framework Interop Group [Архівовано 17 вересня 2015 у Wayback Machine.]
- Python: Style Guide for Python Code [Архівовано 17 травня 2008 у Wayback Machine.]
- Ruby: The Unofficial Ruby Usage Guide [Архівовано 7 вересня 2015 у Wayback Machine.]
- Ruby: GitHub Ruby style guide [Архівовано 13 вересня 2015 у Wayback Machine.]
- Apache Developers' C Language Style Guide [Архівовано 8 вересня 2015 у Wayback Machine.]
- Drupal PHP Coding Standards [Архівовано 16 вересня 2015 у Wayback Machine.]
- Zend Framework Coding Standards [Архівовано 5 вересня 2015 у Wayback Machine.]
- GNU Coding Standards
- Style guides for Google-originated open-source projects [Архівовано 10 травня 2015 у Wayback Machine.]
- Linux Kernel Coding Style (or Documentation/CodingStyle in the Linux Kernel source tree)
- ModuLiq Zero Indent Coding Style
- Mozilla Coding Style Guide [Архівовано 2 грудня 2019 у Wayback Machine.]
- Road Intranet's C++ Guidelines [Архівовано 24 вересня 2015 у Wayback Machine.]
- The NetBSD source code style guide [Архівовано 20 червня 2021 у Wayback Machine.] (formerly known as the BSD Kernel Normal Form)
- OpenBSD Kernel source file style guide (KNF)
- GNAT Coding Style: A Guide for GNAT Developers. GCC online documentation. Free Software Foundation. Архів оригіналу за 4 березня 2016. Процитовано 19 січня 2009. (PDF [Архівовано 5 вересня 2015 у Wayback Machine.])
