Czy średnia liczba błędów na lokalizację jest taka sama dla różnych języków programowania? [Zamknięte]

Powiedziano mi, że średnia liczba błędów / defektów na wiersz kodu jest „stała” dla różnych języków programowania. 10 KLOC Ruby miałoby taką samą liczbę błędów jak 10 KLOC c ++. Argument ten jest zwykle używany do promowania użycia ekspresyjnych języków (pomyśl python / ruby ​​nad c ++ / asembler), ponieważ liczba linii opisujących tę samą funkcjonalność byłaby mniejsza.

Czy ktoś wie, skąd pochodzi to roszczenie? Czy języki wyższego poziomu powodują mniej błędów?

Wbrew intuicji liczba błędów na 1000 wierszy wydaje się być względnie stała, niezależnie od konkretnego języka. Steve McConnell , autor Code Complete i Software Estimation: Demystifying the Black Art szczegółowo omawia ten obszar.

Nie mam pod ręką swoich kopii - siedzą na mojej półce w pracy - ale szybki Google znalazł odpowiedni cytat:

Średnia branżowa: „około 15–50 błędów na 1000 wierszy dostarczonego kodu”.
(Steve) dodaje, że jest to zwykle reprezentatywne dla kodu, który ma pewien poziom programowania strukturalnego, ale prawdopodobnie zawiera mieszankę technik kodowania.

Cytat z Code Complete , można znaleźć tutaj: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Jeśli pamięć służy poprawnie, Steve przechodzi do dokładnej dyskusji na ten temat, pokazując, że liczby są stałe we wszystkich językach (C, C ++, Java, Asembler itd.) I pomimo trudności (takich jak zdefiniowanie, co oznacza „linia kodu”).

Co najważniejsze, ma wiele cytatów ze swoich źródeł - nie oferuje niepotwierdzonych opinii, ale ma odniesienia do ich poparcia.

Wydaje się, że sprowadza się to do tego: średnia liczba defektów na kloc wydaje się być bardziej właściwością faktu, że programiści są omylnymi ludźmi niż szczególnych zalet lub wad konkretnego języka lub platformy.

(Poza tym: jeśli nie masz jeszcze kodu Complete, kup sobie kopię i przeczytaj ją dokładnie - warto zainwestować).

Aktualizacja : W przypadku niektórych odpowiedzi istnieje jeszcze jeden czynnik - statystyki na dużą skalę są przydatne do tworzenia ogólnych prognoz, ale nie konkretnych. Rozważmy, że tabele umieralności populacji mogą przewidywać, ile osób zostanie zabitych w wypadkach drogowych w tym roku, ale nie mogą powiedzieć, które osoby umrą. Podobnie, statystyki branżowe, które pokazują względnie stałą liczbę defektów na kloc, nie mogą być wykorzystane do przewidzenia, jak dobrze - lub jak słabo - będzie działać dany programista lub co stanie się z danym projektem.

Twierdzenie to - w najlepszym razie - naiwne.

SLOC nie jest dokładną miarą niczego użytecznego, z wyjątkiem być może porównania wielkości dwóch lub więcej projektów. Ponadto istnieją dwa różne typy SLOC, fizyczny LOC i logiczny LOC, które mogą się znacznie różnić. Rozważ ten przykład z Wikipedii :

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

Tutaj mamy jeden fizyczny LOC, ale dwa logiczne ( fori printfinstrukcje). Ale możemy oczywiście napisać przykład jako:

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

Co dałoby nam dwa fizyczne i dwa logiczne LOC. Myślę, że jest jasne, że każdy pomiar „błędu na lokalizację”, który zależałby od fizycznych LOC, byłby skażony stylem programowania, dlatego nasz pomiar byłby w dużej mierze bezużyteczny.

Z drugiej strony, jeśli zastosowalibyśmy logiczne LOC, to nasz pomiar w dużym stopniu zależałby od składniowej osobliwości języka. Chociaż wynikowa metryka może być nieco przydatna podczas porównywania projektów napisanych w tym samym języku, byłaby dość bezużyteczna w przypadku projektów napisanych w różnych językach.

Jednym z możliwych źródeł roszczenia są awarie oprogramowania Les Hatton - szaleństwa i błędy :

Możemy stwierdzić, że wybór języka programowania jest w najlepszym razie słabo związany z niezawodnością.

Później w artykule wspomniano o podobnej gęstości defektów dla C i C ++:

W ostatnim badaniu porównującym dwa podobne systemy o podobnej wielkości (około 50 000 linii każdy), jeden w C i jeden w C ++ zaprojektowanym obiektowo, wykazano, że wynikowa gęstość defektów jest w przybliżeniu taka sama przy odpowiednio 2,4 i 2,9 na 1000 linii.

Nie oznacza to jednak, że „błąd na LOC” jest stały we wszystkich językach programowania lub że byłby znaczący, gdyby tak było.

Ta obserwacja jest bardzo stara i pochodzi z bardzo czcigodnego źródła, a mianowicie Freda Brooksa w jego książce „The Mythical Man Month”. Był głównym menadżerem w IBM i zarządzał wieloma projektami programistycznymi, w tym systemem operacyjnym miliony linii OS / 360. W rzeczywistości stwierdził, że liczba błędów w programie nie jest proporcjonalna do długości kodu, ale kwadratowa ! Według jego badań liczba błędów była proporcjonalna do długości programu do mocy 1,5. Innymi słowy, program, który jest dziesięć razy dłuższy, ma 30 razy więcej błędów. I poinformował, że dotyczy to wszystkich języków programowania i poziomów języków programowania.

Nie uważam, aby Błędy na LOC były stałe dla danego języka. Błędy na LOC wydają się miernikiem używanym przez niektórych menedżerów do określania jakości programistów, jeśli chodzi o czas przeglądu.

Poza tym niektóre języki są bardziej podatne na błędy lub wady niż inne. Zwykle, ale nie zawsze, jest to język niższego poziomu niż wyższy. Na przykład kodowanie w C w porównaniu z C # (lub Javą). Mówię zwykle, ponieważ rzeczywistość tego i sedno odpowiedzi, której szukasz, sprowadza się do jakości programisty i stosowanych praktyk kodowania. Widziałem bardzo dobrych programistów C o znacznie wyższej jakości kodu i mniejszej liczbie defektów niż przeciętni programiści Java / C #. Jest to jeden element, który oddziela starszego programistę od młodszego. Nie ile LOC piszą w danym przedziale czasowym, ale jakość kodu, który piszą niezależnie od języka, LOC lub przedziału czasowego.

Jedyną rzeczą, jaką mogę udzielić, która może się odnosić, jest to, że im więcej LOC, tym bardziej prawdopodobne jest istnienie wady i więcej istniejących wad.

Błędy w wierszu kodu

Błędy / LOC dotyczą tylko osoby. Dla firm, które wdrażają narzędzia do śledzenia błędów połączone z repozytorium kodu źródłowego. Menedżer może organizować problemy według programistów, posortowane według wcześniejszych problemów i zmian w kodzie.

Błędy są związane z Twoją pracą

Starszy programista, który jest bardzo doświadczony, wysoko wykwalifikowany, bardzo inteligentny i zdolny do samodzielnego wykonywania zadań, znacznie częściej rejestruje więcej błędów w systemie śledzenia, niż młodszy programista z niewielkim doświadczeniem.

Jak to możliwe?

Starsi programiści są często zaangażowani w zadania związane z rozwojem wyższego ryzyka. Refaktoryzacja kodu i budowanie nowych systemów jako przykład. Młodsi programiści często są przydzielani do rozwiązywania znanych problemów, które nie są warte czasu starszego programisty.

Dlatego przy przydzielaniu zadań młodszy nie wprowadza błędów, ale je naprawia, a starszy programista ma ryzyko ich wprowadzenia, ponieważ korzyści z tego, co próbują zarchiwizować, są ważniejsze niż drobne problemy, które są zgłaszane przy ich uzupełnianiu zadania

Ważna jest składnia języka

Argument, że język wprowadza mniej błędów, ponieważ może osiągnąć więcej przy mniejszej liczbie wierszy kodu, jest kompletnym mitem. Języki o wysokiej strukturze, takie jak C ++ / C # / Java, zmuszają programistę do wyraźnego wyrażenia na piśmie, jaka powinna być pożądana instrukcja, podczas gdy języki takie jak Python / PHP są bardzo nieustrukturyzowane. Te języki pozwalają na wyrażenia pisane, które nie tylko wprowadzą w błąd programistę, ale także parser języka.

Kompilator redukuje błędy

Ile błędów w Python / PHP dostało się na serwery produkcyjne, ponieważ nie było kompilatora ostrzegającego programistę, że coś jest nie tak. Kiedy mierzysz błędy na LOC, czy to przed, czy po kompilacji przetworzył kod źródłowy?

Aktualizacja 2019:

Kompilatory nie mają wpływu na naturę ani liczbę błędów. Błędy dotyczą wyłącznie osoby, która napisała kod źródłowy, a same błędy mogą mieć bardzo subiektywny charakter.

FWIW, z mojego doświadczenia

1. Istnieją dwa rodzaje błędów: a) w których program nie spełnia oczekiwań, i b) w których program nie może spełnić żadnych uzasadnionych oczekiwań, ponieważ ulega awarii / zawiesza się / nie kompiluje.

2. Bez względu na język, błędy typu (b) są spowodowane przez nadmiarowość w strukturze danych / klasy, gdzie zmiana czegoś w jednej części struktury danych powoduje, że struktura jest niespójna / uszkodzona, dopóki jedna lub więcej odpowiednich zmian nie zostanie wprowadzonych w innych częściach . Przyczynia się do tego nadmiarowość kodu źródłowego, gdzie edycja jednego wiersza kodu powoduje, że kod jest niepoprawny, dopóki jedna lub więcej zmian nie zostanie wprowadzonych w innych częściach. Te dwa rodzaje redundancji są oczywiście ściśle ze sobą powiązane, a ponieważ programiści nie są superosobami, rozpraszają się, zapominają o rzeczach i popełniają błędy, co powoduje błędy.

Te rzeczy (znowu, z mojego doświadczenia) nie są tak naprawdę funkcją języka, ale umiejętności / dojrzałości programisty. Programy, które są znacznie mniej podatne na błędy, są zwykle znacznie mniejsze pod względem LOC dla danego zestawu funkcji.

Widziałem systemy, w których niektórzy piszą programy, podczas gdy inni piszą katalogi, a te pierwsze „po prostu działają” w porównaniu do drugiego.

Spodziewałbym się, że kluczowy czynnik w błędach kodowania odnosi się do tego, co nazywam „luką semantyczną” między konkretnym rodzajem definicji rozwiązania a kodem do jego rozwiązania - tam gdzie są to bliskie błędy przeformułowania byłyby bardziej widoczne, gdzie kod jest bardzo inaczej, można się spodziewać wielu błędów. Paradygmat niektórych języków jest ściśle zgodny z pewnymi domenami problemowymi - arkusze kalkulacyjne są bardzo odpowiednie do codziennych obliczeń biznesowych, co powoduje, że zarówno bardzo mało „kodu”, jak i „kodu” jest bardzo zbliżony do dziedziny problemowej. Oczekiwany kod jest bardzo zwięzły (mało KLOC) i mało błędów. I odwrotnie, użycie asemblera wymagałoby wielu KLOC i prawdopodobnie spowoduje ogromną liczbę błędów.

Zamiast mówić o wierszach kodu - które są rzeczywiście bezużytecznymi wskaźnikami - chciałbym odpowiedzieć na tę część pytania:

Czy języki wyższego poziomu powodują mniej błędów?

Różni się to od błędów / LOC, ponieważ języki wyższego poziomu robią więcej przy mniejszym kodzie. Wdrożenie niektórych wymagań funkcji może zająć 500 linii LISP w porównaniu z 15000 liniami zestawu x86.

Tak więc, nawet jeśli błędy / LOC są stałe między wszystkimi językami, język wyższego poziomu nadal będzie generował mniej błędów.