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

45

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?

Kristian
źródło
11
Wydaje się nieuzasadnione, biorąc pod uwagę, że niektóre języki zachęcają do stylu, który zawiera więcej instrukcji w jednym wierszu niż inne.
Caleb
10
Błędy / LOC to bardzo zły wskaźnik dla wszystkiego. To zależy od języka, ale znacznie bardziej zależy od programisty, który go pisze. Zatem przyjęcie średniej dla języka nie ma sensu, ponieważ duże fluktuacje występują w drugiej zmiennej. To tylko IMO, ofc.
K.Steff
3
Mogę powiedzieć, że liczba błędów / linii, które piszę w Perlu, będzie znacznie większa niż liczba, którą piszę w C. Mój przyjaciel jest czarodziejem Perla, a dla niego błędy / linii są znacznie większe w C niż w Perl Trudno zrozumieć, w jaki sposób ta metryka może być przydatna.
Caleb
2
Właśnie natrafiłem na to pytanie. Nie mam najmniejszego pojęcia, dlaczego został zamknięty; to idealne pytanie dla tej strony. W przypadku dużego projektu błędy na KLOC nie są miarą tego, jak dobrzy są programiści. Jest to miara tego, jak dobra jest organizacja i proces.
David Hammen

Odpowiedzi:

43

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.

Bevan
źródło
4
Nie mam kopii Oceny oprogramowania, ale w Code Complete McConnel cytuje raport Capers Jones „Jakość programu i produktywność programisty” z 1977 r. Jako źródło tabeli błędów dla LOC według wielkości projektu. Rzeczą McConnela jest to, że błędy dramatycznie rosną wraz ze wzrostem wielkości projektu, i zauważa, że ​​dane są jedynie „snapgotem branży” i że „liczby mogą w niewielkim stopniu przypominać te dla projektów, nad którymi pracowałeś „. Naprawdę nie widzę tam nic, co ma coś wspólnego z tym pytaniem.
Roc Martí
Którą edycję Code Complete masz @ RocMartí? Wiem, że drugie wydanie było ważną aktualizacją. Będę musiał go wykopać i zobaczyć, co powie, kiedy w poniedziałek przyjdę do pracy.
Bevan
Myślę, że twoja edycja ( aktualizacja:) jest rdzeniem problemu. Lub, jak powiedział Mark Twain, istnieją trzy rodzaje kłamstw: kłamstwa, przeklęte kłamstwa i statystyki.
GalacticCowboy
1
@ RocMartí ”błędy dramatycznie rosną wraz ze wzrostem wielkości projektu” Czy zwrócił również uwagę, że woda jest mokra? Oczywiście występują błędy, gdy sprawy stają się bardziej skomplikowane. Ponieważ każda nowa zmiana musi mieć na uwadze każdy możliwy element, na który może mieć wpływ. Który rośnie wraz z rozwojem projektu.
Parthian Shot
3
Cytat jest błędny lub nieaktualny. W drugim wydaniu jest na stronie 521: „Średnie doświadczenie w branży wynosi około 1–25 błędów na 1000 wierszy kodu dostarczonego oprogramowania. Oprogramowanie zwykle opracowywano przy użyciu mnóstwa technik”.
Aryeh Leib Taurog
18

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.

Yannis
źródło
Jeśli założysz, że błędy / instrukcje są stałe, istnieje różnica dla języków. Przykład C często zawiera błędy w argumentach for () i printf (). Gdybyś musiał w pełni zakodować funkcjonalność printf, miałbyś proporcjonalnie więcej błędów, a gdybyś miał wyższy poziom języka z pojedynczym wywołaniem printRepeat (), byłoby mniej okazji, aby go pomylić.
Martin Beckett
2
Podsumowanie: błędy na instrukcję / punkt funkcyjny są stałe, języki niskiego poziomu mają więcej kodu napisanego przez omylnego programistę, języki wysokiego poziomu wpisujesz mniej - a zatem mniej błędów. Chociaż całkowicie niepoprawne typy błędów konstrukcyjnych są prawdopodobnie takie same!
Martin Beckett
2
Nie mówiąc już o tym, że to, co stanowi „jeden błąd”, jest wysoce subiektywne i że błędy różnią się znacznie pod względem dotkliwości, wpływu i ważności.
tdammers
@tdammers I to znaczenie może być negatywne. Mamy garść błędów, do których klient jest przyzwyczajony / oczekuje / chce, więc nie możemy ich naprawić ...
Izkata
@Izkata: zależy od twojej definicji błędu ...
tdammers
12

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.

Steven Pemberton
źródło
6

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.

Akira71
źródło
Moje pytanie dotyczy średniej liczby defektów na wiersz kodu niezależnie od języka.
Kristian
4
@Kristian nie ma takiego numeru. Zmienia się na osobę w zależności od zawodu i wiedzy programisty oraz języka, w którym kodują. Nie sądzę, aby istniała uniwersalna średnia.
Akira71
1
@ Akira71 „nie ma takiego numeru” Cóż, jasne. Ale istnieją rozkłady prawdopodobieństwa, z których można wydobywać liczby. Nie ma też liczby, ile centymetrów deszczu spada rocznie w lasach deszczowych Amazonii, ale możesz wziąć średnią.
Parthian Shot
3

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.

Reactgular
źródło
3
Re kompilator redukujący błędy: Zarówno Python, jak i PHP mają technicznie kompilatory, po prostu nie robią tego samego sprawdzania, co robią statycznie typowane języki. Nie zgadzam się również, że takie sprawdzanie ma znaczący wpływ na liczbę zakończonych błędów, ponieważ praktycznie wszystkie błędy, które mogą zostać wychwycone przez kompilator, są wychwytywane przy minimalnym testowaniu.
Winston Ewert
3
Uzgodniono, że błędy, które mogą zostać przechwycone przez kompilator, zostaną na ogół wykryte za pomocą rozsądnych testów automatycznych lub ręcznych. Różnica polega na tym, że statycznie wpisane języki dają ci pierwszy test (a) za darmo i (b) naprawdę bardzo szybko. Dobry zestaw testów jednostkowych Ruby jest lepszy niż kompilator, ale zwykle nie można uruchomić ich tak szybko, nie dostaje się ich za darmo i zwykle nie wskazują tak blisko wiersza kodu, który jest problem.
Ken Smith
@KenSmith typy statyczne nie są darmowe. Kursy.cs.washington.edu/courses/cse590n/10au/…
Hugo Wood
1

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.

Mike Dunlavey
źródło
1

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.

Andreas Dinkelacker
źródło
jak to było przegłosowane? SO
zapełnia się
0

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.

Misko
źródło
2
Linie kodu „bezużyteczną miarą”? Nie, jest to przybliżone przybliżenie złożoności programu. Może być przydatny, ponieważ jest łatwy do zmierzenia i jest ściśle powiązany z czasem rozwoju.