로크 당 평균 버그 수는 다른 프로그래밍 언어에 대해 동일합니까? [닫은]

코드 라인 당 평균 버그 / 결함 수는 다른 프로그래밍 언어에 대해 "일관 적"이라고 들었습니다. 10 KLOC of Ruby는 10 KLOC의 c ++와 동일한 수의 버그를가집니다. 인수는 일반적으로 동일한 기능을 설명하는 줄 수가 적기 때문에 표현 언어 (python / ruby ​​over c ++ / assembly)의 사용을 촉진하는 데 사용됩니다.

이 주장의 출처를 아는 사람이 있습니까? 고급 언어는 버그를 줄입니까?

직감과는 달리, 1000 줄 당 오류 수는 관련된 특정 언어를 지키지 않고 비교적 일정하게 보입니다. Code Complete 및 Software Estimation : Demystifying the Black Art의 저자 인 Steve McConnell 은이 영역을 자세히 설명합니다.

사본을 가지고 있지 않습니다. 직장에서 책꽂이에 앉아 있지만 빠른 Google에서 관련 견적을 찾았습니다.

업계 평균 : "제공된 코드 1000 줄당 약 15-50 개의 오류"
(스티브)는 이것이 일반적으로 어떤 수준의 구조적 프로그래밍을 가진 코드를 대표하지만 아마도 코딩 기술의 혼합을 포함한다고 말합니다.

코드 완성 에서 인용 , 여기에 있습니다 : http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

메모리가 올바르게 작동하면 Steve는 이에 대해 철저히 논의하여 수치가 언어 (C, C ++, Java, Assembly 등)에 걸쳐 일정하며 어려움 ( "코드 라인"의 의미 정의와 같은)에도 불구하고 있음을 보여줍니다.

가장 중요한 것은 자신의 출처에 대한 인용이 많이 있다는 것입니다. 그는 근거없는 의견을 제시하지는 않지만이를 뒷받침하는 언급을합니다.

kloc 당 평균 결함 수는 개발자가 특정 언어 또는 플랫폼의 고유 한 장점이나 단점보다 오류가 많은 사람이라는 사실의 더 큰 속성 인 것처럼 보입니다.

(제외 : Code Complete가없는 경우 직접 구매하여 자세히 읽어보십시오. 투자 가치가 있습니다.)

업데이트 : 여기에 대한 답변과 함께 또 다른 요인이 있습니다. 대규모 통계는 일반적인 예측에는 유용하지만 특정 예측에는 유용하지 않습니다. 인구 사망률 표는 올해 교통 사고로 사망 한 사람 수를 예측할 수 있지만 어떤 사람이 죽을지는 알 수 없습니다. 마찬가지로, kloc 당 비교적 일정한 수의 결함을 보여주는 산업 통계를 사용하여 특정 개발자가 얼마나 잘 수행하는지 또는 얼마나 빈약하게 수행하는지 또는 주어진 프로젝트에서 어떤 일이 발생할지 예측할 수 없습니다.

주장은 기껏해야 순진합니다.

SLOC는 두 개 이상의 프로젝트의 크기를 비교하는 것을 제외하고는 유용한 정보에 대해 정확하게 신뢰할 수있는 지표가 아닙니다. 또한 SLOC에는 물리적 LOC와 논리적 LOC의 두 가지 유형이 있으며 크게 다를 수 있습니다 . Wikipedia의 다음 예제를 고려하십시오 .

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

여기에는 하나의 물리적 LOC가 있지만 두 개의 논리적 LOC ( for및 printf명령문)가 있습니다. 그러나 물론 예를 다음과 같이 작성할 수 있습니다.

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

두 개의 물리적 LOC와 두 개의 논리적 LOC를 제공합니다. 실제 LOC에 의존하는 "loc per loc"측정은 프로그래밍 스타일에 의해 오염 될 것이므로 측정이 크게 쓸모 없다고 생각합니다.

반면에 논리적 인 LOC를 사용한다면 언어의 구문 특유성에 따라 측정이 크게 좌우됩니다. 결과 메트릭 은 같은 언어로 작성된 프로젝트를 비교할 때 약간 유용 할 수 있지만 다른 언어로 작성된 프로젝트에는 상당히 쓸모가 없습니다.

클레임의 가능한 원인 중 하나는 Les Hatton의 소프트웨어 장애 및 오류입니다 .

우리는 프로그래밍 언어 선택이 신뢰성과 약하게 관련되어 있다는 결론을 내릴 수 있습니다.

나중에이 논문은 C와 C ++에 대해 비슷한 결함 밀도를 언급합니다.

비슷한 크기의 비슷한 두 시스템 (각각 약 50,000 줄), 하나는 C, 다른 하나는 객체 설계 C ++을 비교 한 최근 연구에서 결과 결함 밀도는 각각 1000 줄당 2.4와 2.9에서 거의 비슷한 것으로 나타났습니다.

그러나 이것이 "LOC 당 버그"가 프로그래밍 언어에서 일정하거나 의미가있는 것은 아니라는 의미는 아닙니다.

이 관찰은 매우 오래되었고 매우 유명한 출처, 즉 Fred Brooks의 저서 "The Mythical Man Month"에서 나온 것입니다. 그는 IBM의 최고 관리자였으며 여러 운영 체제 OS / 360을 포함한 많은 프로그래밍 프로젝트를 관리했습니다. 실제로 그는 프로그램의 버그 수가 코드 길이에 비례하지 않고 이차적 이라고보고했다 . 그의 연구에 따르면 버그의 수는 프로그램의 길이에 비례하여 1.5입니다. 다시 말해, 10 배 더 긴 프로그램에는 30 배 더 많은 버그가 있습니다. 그리고 그는 이것이 모든 프로그래밍 언어와 수준의 프로그래밍 언어를 지배한다고보고했습니다.

주어진 언어에 대해 LOC 당 버그가 전혀 일정하지 않습니다. LOC 당 버그는 검토 시간과 관련하여 일부 관리자가 개발자의 품질을 결정하는 데 사용하는 지표와 같습니다.

이제는 언어 이외의 언어에서는 다른 언어보다 오류나 결함이 발생하기 쉽습니다. 일반적으로 항상 그런 것은 아니지만 상위 언어보다 하위 언어입니다. 예를 들어 C 대 C # (또는 Java)로 코딩하는 것은 필자가 일반적으로 말하는 것의 현실과 당신이 찾고있는 대답의 핵심이 개발자의 품질과 코딩 방법에 달려 있기 때문입니다. 나는 일반적인 Java / C # 개발자보다 훨씬 높은 코드 품질과 낮은 결함 수를 가진 매우 우수한 C 개발자를 보았습니다. 상급 개발자와 후배 개발자를 구분하는 항목입니다. 주어진 시간 프레임에서 몇 개의 LOC를 작성 하느냐가 아니라 언어, LOC 또는 시간 프레임에 관계없이 코드의 품질이 기록됩니다.

내가 말할 수있는 유일한 대답은 LOC가 많을수록 결함이있을 가능성이 높고 결함이 더 많을 가능성이 있다는 것입니다.

코드 라인 당 버그

버그 / LOC는 개인과 관련이 있습니다. 소스 코드 저장소와 연결되는 버그 추적 도구를 구현하는 비즈니스에 적합합니다. 관리자가 개발자별로 이슈를 구성 할 수 있으며 과거 이슈 및 코드 변경 사항별로 정렬 할 수 있습니다.

버그는 직업과 관련이 있습니다

경험이 많고 숙련되고 똑똑하며 독립적 인 업무를 수행 할 수있는 선임 소프트웨어 개발자는 추적 시스템에 더 많은 버그가 기록 될 가능성이 훨씬 높으며 경험이 적은 후배 개발자입니다.

어떻게 가능합니까?

선임 개발자는 종종 더 높은 위험 개발 작업에 참여합니다. 예를 들어 코드 리팩토링 및 새로운 시스템 구축. 주니어 개발자는 종종 수석 개발자의 시간이 아닌 알려진 문제를 해결하도록 배정됩니다.

따라서, 과제를 배정함으로써 후배는 버그를 도입하지 않고 문제를 해결하게되며, 상급 개발자는 버그를 도입 할 위험이 있습니다. 왜냐하면 아카이브하려는 것의 이점이 버그를 완성시키는 작은 문제보다 중요하기 때문입니다. 작업.

언어 구문이 중요합니다

더 적은 수의 코드 줄에서 더 많은 것을 달성 할 수 있기 때문에 언어가 더 적은 버그를 도입한다는 주장은 완전한 신화입니다. C ++ / C # / Java와 같이 고도로 구조화 된 언어는 개발자가 Python / PHP와 같은 언어가 매우 구조화되지 않은 곳에서 원하는 명령어를 작성하여 명확하게 표현하도록합니다. 이러한 언어를 사용하면 개발자뿐만 아니라 언어 파서를 혼동시킬 수있는 서면 표현이 가능합니다.

컴파일러로 버그 감소

개발자에게 무언가 잘못되었음을 경고하는 컴파일러가 없었기 때문에 Python / PHP의 버그로 인해 프로덕션 서버에 버그가 발생했습니다. LOC 당 버그를 측정 할 때 컴파일러가 소스 코드를 처리하기 전후에 발생합니까?

2019 업데이트 :

컴파일러는 버그의 성격이나 수에 영향을 미치지 않습니다. 버그는 순수하게 소스 코드를 작성한 사람과 관련이 있으며 버그 자체는 본질적으로 매우 주관적 일 수 있습니다.

FWIW, 내 경험에

1. 두 가지 종류의 버그가 있습니다 : a) 프로그램이 기대를 충족시키지 못하는 경우 b) 프로그램이 충돌 / 매달 리거나 컴파일되지 않기 때문에 프로그램이 합리적인 기대치를 충족 할 수없는 경우

2. 언어에 관계없이 (b) 유형의 버그는 데이터 / 클래스 구조의 중복으로 인해 발생합니다. 데이터 구조의 한 부분에서 무언가를 변경하면 다른 부분에서 하나 이상의 해당 변경이 이루어질 때까지 구조가 일치하지 않는 / 깨진 상태가됩니다. . 이에 기여하는 것은 한 줄의 코드를 편집하면 다른 부분에서 하나 이상의 변경이 이루어질 때까지 코드를 잘못 수정하는 소스 코드의 중복입니다. 이 두 가지 유형의 중복은 물론 밀접한 관련이 있으며 프로그래머는 슈퍼 인이 아니기 때문에 산만하고 물건을 잊어 버리고 실수를함으로써 버그가 발생합니다.

이러한 것들 (내 경험상)은 실제로 언어의 기능이 아니라 프로그래머의 기술 / 성숙도입니다. 버그가 발생하기 쉬운 프로그램은 LOC 측면에서 특정 기능 집합에 대해 훨씬 작은 경향이 있습니다.

나는 어떤 사람들은 프로그램을 쓰는 반면 다른 사람들은 디렉토리를 쓰는 시스템을 보았고 전자는 후자에 비해 "그냥 작동하는"경향이있다.

코딩 오류의 주요 요인은 특정 유형의 솔루션 정의와이를 해결하기위한 코드 사이의 "의미 적 차이"와 관련이있을 것으로 예상됩니다. 다른 많은 오류가 예상 될 수 있습니다. 특정 언어의 패러다임은 특정 문제 영역과 밀접하게 일치합니다. 스프레드 시트는 일상적인 비즈니스 계산에 매우 적합하므로 "코드"와 "코드"가 거의 문제 영역과 매우 비슷합니다. 예상되는 코드는 매우 간결하고 (작은 KLOC) 오류가 거의 없습니다. 반대로 어셈블러를 사용하면 많은 KLOC가 필요하며 엄청난 수의 오류가 발생할 수 있습니다.

실제로 쓸모없는 메트릭 인 코드 줄에 대해 이야기하는 대신 귀하의 질문 의이 부분을 해결하고 싶습니다.

고급 언어는 버그를 줄입니까?

고급 언어는 코드가 적을수록 더 많은 기능을 수행하므로 버그 / LOC와 다릅니다. 일부 기능 요구 사항을 구현하려면 500 줄의 LISP와 15000 줄의 x86 어셈블리가 필요할 수 있습니다.

따라서 모든 언어간에 버그 / LOC가 일정하더라도 고급 언어를 사용하면 버그가 줄어 듭니다.