Чи однакова середня кількість помилок у локальній мережі для різних мов програмування? [зачинено]

Мені сказали, що середня кількість помилок / дефектів у рядку коду є "постійною" для різних мов програмування. 10 KLOC Ruby матиме таку ж кількість помилок, що й 10 KLOC c ++. Аргумент зазвичай використовується для сприяння використанню експресивних мов (думаю, python / ruby ​​over c ++ / Assembly), оскільки кількість рядків для опису тієї ж функціональності буде меншою.

Хтось знає, звідки ця претензія? Мови вищого рівня призводять до меншої кількості помилок?

На відміну від інтуїції, кількість помилок на 1000 рядків здається відносно постійною, незалежно від конкретної мови. Стів МакКоннелл , автор " Кодексу повного" та " Оцінка програмного забезпечення: Демістифікація чорного мистецтва" детально висвітлює цю область.

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

Середня галузь: "близько 15 - 50 помилок на 1000 рядків доставленого коду."
(Стів) далі каже, що зазвичай це представник коду, який має за собою певний рівень структурованого програмування, але, ймовірно, включає поєднання методів кодування.

Цитується з Code Complete , знайдений тут: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Якщо пам'ять служить правильно, Стів іде на ретельне обговорення цього, показуючи, що цифри є постійними для різних мов (C, C ++, Java, Assembly та ін.) І незважаючи на труднощі (наприклад, визначення того, що означає "рядок коду").

Найголовніше, що у нього є багато цитат до своїх джерел - він не пропонує необгрунтованих думок, але має посилання на їх підтримку.

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

(Убік: Якщо у вас ще немає Code Complete, купіть собі копію та прочитайте її ретельно - це варте інвестицій.)

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

Претензія - у кращому випадку - наївна.

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

for (i = 0; i < 100; i += 1) printf("hello"); 

Тут ми маємо один фізичний LOC, але два логічні ( forта printfтвердження). Але ми, звичайно, могли написати приклад так:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

Що дало б нам два фізичні та два логічні локальні точки. Я думаю, що зрозуміло, що будь-яке вимірювання "помилка на місце", яке залежало б від фізичних локальних місць, було б пошкоджене стилем програмування, тому наше вимірювання було б в основному марним.

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

Одним із можливих джерел претензії є збої в програмах Les Hatton Software :

Можна зробити висновок, що вибір мови програмування в кращому випадку пов'язаний із надійністю.

Пізніше в статті згадуються аналогічні щільності дефектів для C і C ++:

У недавньому дослідженні, що порівнювало дві подібні системи однакового розміру (по 50 000 рядків у кожній), одну на С та іншу в об'єктно-розробленій C ++, отримані щільності дефектів були приблизно однаковими на рівні 2,4 та 2,9 на 1000 ліній відповідно.

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

Це спостереження дуже старе, і походить з дуже поважного джерела, а саме Фреда Брукса у своїй книзі "Міфічний місяць людини". Він був головним менеджером IBM і керував багатьма проектами програмування, включаючи мільйонні операційні системи OS / 360. Насправді він повідомив, що кількість помилок у програмі не пропорційна довжині коду, а квадратична ! Згідно з його дослідженнями, кількість помилок була пропорційна довжині програми до потужності 1,5. Іншими словами, програма, яка в десять разів більше, має помилки в 30 разів. І він повідомив, що це стосується всіх мов програмування та рівнів мов програмування.

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

Зараз поза цим деякі мови більш схильні до помилок чи дефектів, ніж інші. Зазвичай, але не завжди це мова нижчого рівня, ніж вища. Наприклад, кодування в C проти C # (або Java.) Я кажу, як правило, тому, що реальність цього і суть відповіді, яку ви шукаєте, зводиться до якості розробника та застосованих методів кодування. Я бачив дуже хороших розробників C із значно вищою якістю коду та меншим числом дефектів, ніж середні розробники Java / C #. Це один предмет, який відокремлює старшого розробника від молодшого. Не скільки LOC вони записують у заданому часовому діапазоні, а якість коду, що пише, незалежно від мови, LOC або часових рамок.

Єдине, на що я можу дати відповідь, це те, що чим більше LOC, тим більше шансів на випадок дефекту і тим більше дефектів.

Помилки за рядком коду

Помилки / LOC стосується лише окремих осіб. Для підприємств, які використовують інструменти відстеження помилок, які пов'язують їх із сховищем вихідного коду. Менеджер може організувати проблеми розробника, відсортовані за попередніми проблемами та змінами коду.

Помилки відносно вашої роботи

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

Як це можливо?

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

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

Синтаксис мови важливий

Аргумент того, що мова вводить менше помилок, тому що може досягти більшого за меншу кількість рядків коду, є повним міфом. Високоструктуровані мови на зразок C ++ / C # / Java змушують розробника чітко письмово висловити бажану інструкцію, коли такі мови, як Python / PHP, дуже неструктуровані. Ці мови дозволяють писати вирази, які не тільки збивають з пантелику розробника, але й мовний аналізатор.

Компілятор зменшує помилки

Скільки помилок у Python / PHP зробили це на виробничі сервери, оскільки не було компілятора, який би попереджав розробника про те, що щось невірно. Коли ви вимірюєте помилки на LOC, це до чи після того, як компілятор обробив вихідний код?

Оновлення 2019 року:

Компілятори не мають різниці в природі та кількості помилок. Помилки мають відношення до людини, яка написала вихідний код, а самі помилки можуть мати дуже суб'єктивний характер.

FWIW, на мій досвід

1. Існують два типи помилок: а) там, де програма не відповідає очікуванням, і б) коли програма не може відповідати жодним розумним очікуванням, оскільки вона збоїться / висить / не складеться.

2. Незалежно від мови, помилки типу (b) викликаються надмірністю у структурі даних / класів, коли зміна чогось в одній частині структури даних переводить структуру в непослідовний / порушений стан, поки не будуть внесені одні або більше відповідних змін в інші частини . Цьому сприяє надмірність вихідного коду, коли редагування одного рядка коду робить код невірним, поки не будуть внесені одна чи кілька змін в інші частини. Ці два типи надмірності, звичайно, тісно пов’язані між собою, і оскільки програмісти не є надлюдинами, вони відволікаються, забувають речі та роблять помилки, тим самим вводячи помилки.

Ці речі (знову ж таки, на мій досвід) насправді не є функцією мови, а вмінням / зрілістю програміста. Програми, які значно менше схильні до помилок, також, як правило, значно менші, з точки зору LOC, для заданого набору функціональних можливостей.

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

Я б очікував, що ключовий фактор помилок кодування стосується того, що я називаю "семантичним розривом" між певним типом визначення рішення та кодом для його вирішення - там, де це тісні помилки переформулювання, було б більш очевидним, де код дуже різні, багато помилок можна було очікувати. Парадигма певних мов тісно відповідає певним проблемним областям - електронні таблиці дуже підходять до повсякденних бізнес-обчислень, в результаті чого і дуже мало "коду", і "код" дуже близький до проблемної області. Очікуваний код є дуже стислим (мало KLOC) і мало помилок. І навпаки, використання асемблера зажадає багатьох KLOC і, ймовірно, призведе до величезної кількості помилок.

Замість того, щоб говорити про рядки коду - які насправді є марною метрикою - я хотів би вирішити цю частину вашого питання:

Мови вищого рівня призводять до меншої кількості помилок?

Це відрізняється від помилок / LOC, оскільки мови вищого рівня роблять більше з меншим кодом. Реалізація деяких вимог до функції може зайняти 500 рядків LISP проти 15000 рядків складання x86.

Отже, навіть якщо помилки / LOC є постійними між усіма мовами, мова вищого рівня все одно призведе до меншої кількості помилок.