Помилки, яких можна уникнути за допомогою стандартів кодування [закрито]

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

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

Ось дві роботи, які вивчають статистичний вплив звукового процесу інженерії програмного забезпечення на зменшення дефектів, який ви можете використовувати як вихідний пункт:

• Програма зменшення дефектів програмного забезпечення «Топ-10» , де досліджуються вдосконалення в емпіричній основі програмної інженерії з 1987 року
• Критичний аналіз процесу обробки даних PSP , який вивчає статистику, зібрану в процесі персонального програмного забезпечення, та вплив PSP на загальні причини помилок програмного забезпечення

Кодування "стандартів" ... Є багато напрямків розвитку, які можна стандартизувати. Ми говоримо про умови кодування, такі як стандарти називання тощо? Або ми говоримо про щось глибше, як TDD / BDD, CI тощо?

Я можу вам сказати, що дотримання методології "тест-перше", що примушує CI проходити тести та добре охоплювати код, зменшує кількість помилок, виявлених клієнтом. Автоматизоване тестування як розробником, так і QA також є відносно «дешевим» способом пошуку помилок, оскільки вони, як правило, мають дуже короткий час зворотного зв'язку. Ви можете знати, що ви не написали те, що думали, що написали, провівши одиничні тести приблизно 45 секунд. Через пару годин інтеграційних тестів знайдуться місця, де з'єднання речей не пройшло так, як було заплановано, а автоматичне тестування та автоматичне тестування інтерфейсу дозволяє швидко виявити функціональні несправності програмного забезпечення на дуже високому рівні.

Вони також запобігають регресу. Ви знайшли помилку. Ви пишете тест, який доведе, що поведінка більше не виникає, кодуєте, поки тест не пройде, і тепер у вас є тест, який з цього моменту вперед забезпечить, що помилка ніколи більше не буде проблемою. Це, на мій досвід, головне джерело нових помилок; виправлення однієї речі порушує щось інше, і тестування виправлення розробника може не покрити ту іншу ситуацію, яка зараз порушена. Порушення речей, які раніше працювали - це ВЕЛИЧЕЗНИЙ червоний прапор для ваших клієнтів.

Нарешті, ця автоматизована структура тестування, яку ви будуєте в рамках цієї методології, дуже легко створить вам середовище, де ви зможете випустити нове складання програмного забезпечення буквально за мить. "Гей, ця помилка, яку ви щойно виправили, викликає справжні головні болі; коли ви будете готові в новій версії?" натисніть "О, приблизно за 5 хвилин, коли сервер збірки закінчить публікацію його на сторінці завантаження".

Щодо основних умов кодування, таких як стандартизація назв змінних тощо, я вважаю, що більшість із них є менш корисними та більш дратуючими. Це такі стандарти, які "чудові, тому що їх так багато на вибір". Те, що ви сприймаєте як різницю між ідентифікатором PascalCased та camelCased, може бути не тим, що думає хтось інший. Провідні підкреслення, обмеження довжини імен (або вимоги, які імена методів / полів розповідають про історію); крім конвенцій, застосованих компілятором або які зазвичай бачать у специфічному для бібліотеки коді, сучасний IDE може повідомити вам все, що вам потрібно знати про змінну чи функцію, включаючи, чи потрібно чи не слід намагатися використовувати її в певній обставина. Крім того, запуск перевірки конвенції коду часто повертає проблеми з кодом, який ви не можете чи не робите ' не хочете змінитись, як-от стороння бібліотека, яка використовувала інший набір стандартів, або код interop, який може відповідати стандартам іменування Win API замість стандартів вашої рідної мови. Ви в кінцевому підсумку додаєте крафт до свого коду, щоб сказати вашому інструменту ігнорувати суть у коді.

Кожна вразливість ін'єкцій SQL - це дефект, який можна було запобігти стандартом кодування. Статистика щодо вразливості SQL-ін'єкцій є AFAIK.

Кожна вразливість переповнення буфера могла бути запобіжена стандартом кодування. Напевно, є і статистика щодо них.