Одинаково ли среднее количество ошибок на лок для разных языков программирования? [закрыто]

Мне сказали, что среднее количество ошибок / дефектов на строку кода является «постоянным» для разных языков программирования. 10 KLOC в Ruby будут иметь столько же ошибок, сколько 10 KLOC в c ++. Аргумент обычно используется для поощрения использования выразительных языков (например, python / ruby ​​вместо c ++ / assembly), поскольку число строк, описывающих ту же функциональность, будет меньше.

Кто-нибудь знает, откуда это требование? Языки более высокого уровня приводят к меньшему количеству ошибок?

Вопреки интуиции, число ошибок на 1000 строк кажется относительно постоянным, независимо от конкретного языка. Стив Макконнелл , автор « Полного кода и оценки программного обеспечения: демистификация черного искусства», подробно рассматривает эту область.

У меня нет готовых копий копий - они сидят на моей книжной полке на работе - но быстрый Google нашел соответствующую цитату:

Средний показатель по отрасли: «около 15-50 ошибок на 1000 строк доставленного кода».
(Стив) далее говорит, что это обычно представитель кода, который имеет некоторый уровень структурированного программирования, но, вероятно, включает в себя сочетание методов кодирования.

Цитируется из полного кода , можно найти здесь: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Если память работает правильно, Стив подробно обсуждает это, показывая, что цифры постоянны для разных языков (C, C ++, Java, Assembly и т. Д.) И несмотря на трудности (например, определение значения «строки кода»).

Самое главное, у него есть много ссылок на его источники - он не предлагает необоснованных мнений, но имеет ссылки, чтобы поддержать их.

Кажется, это сводится к следующему: среднее число дефектов на kloc, скорее, является скорее свойством того факта, что разработчики являются ошибочными людьми, чем специфических преимуществ или недостатков конкретного языка или платформы.

(Кроме того: если у вас еще нет Code Complete, купите себе копию и внимательно ее прочитайте - она ​​того стоит.)

Обновление : здесь есть еще один фактор, влияющий на некоторые ответы: крупномасштабная статистика полезна для общих, но не конкретных прогнозов. Учтите, что таблицы смертности населения могут предсказать, сколько людей погибнет в результате дорожно-транспортных происшествий в этом году, но не могут сказать, какие люди умрут. Точно так же отраслевая статистика, которая показывает относительно постоянное количество дефектов на kloc, не может быть использована для прогнозирования того, насколько хорошо (или насколько плохо) будет работать конкретный разработчик или что произойдет в данном проекте.

Претензия в лучшем случае наивна.

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. Я думаю, что ясно, что любое измерение «ошибка на место», которое будет зависеть от физических LOC, будет испорчено стилем программирования, поэтому наше измерение будет в значительной степени бесполезным.

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

Один из возможных источников претензий - ошибки и ошибки Программного обеспечения Les Hatton :

Можно сделать вывод, что выбор языка программирования в лучшем случае слабо связан с надежностью.

Позже в статье упоминаются одинаковые плотности дефектов для C и C ++:

В недавнем исследовании, в котором сравнивались две подобные системы одинакового размера (около 50 000 строк в каждой), одна в C и одна в объектно-ориентированном C ++, было показано, что плотность получаемых дефектов примерно одинакова и составляет 2,4 и 2,9 на 1000 линий соответственно.

Это, однако, не означает, что «ошибка на LOC» постоянна для всех языков программирования или что это было бы существенно, если бы это было так.

Это наблюдение очень старое и исходит из очень почтенного источника, а именно Фреда Брукса в его книге «Мистический месяц человека». Он был топ-менеджером в IBM и руководил многими проектами в области программирования, в том числе операционной системой Milons-of-Line на 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 постоянны между всеми языками, язык более высокого уровня все равно будет давать меньше ошибок.