Co to jest kod ujemny?

Odpowiedzi:

501

Oznacza to redukcję linii kodu poprzez usunięcie redundancji lub użycie bardziej zwięzłych konstrukcji.

Zobacz na przykład tę słynną anegdotę oryginalnego zespołu programistów Apple Lisa:

Gdy zespół Lisa naciskał na sfinalizowanie swojego oprogramowania w 1982 r., Kierownicy projektów zaczęli wymagać od programistów składania cotygodniowych formularzy raportujących liczbę napisanych linii kodu. Bill Atkinson pomyślał, że to głupie. W tygodniu, w którym przepisał procedury obliczania regionu QuickDraw, aby był sześciokrotnie szybszy i 2000 wierszy krótszy, umieścił na formularzu „-2000”. Po kilku tygodniach menadżerowie przestali prosić go o wypełnienie formularza i chętnie się zgodził.

Thilo
źródło
257
Doskonałość jest osiągana, nie wtedy, gdy nie ma już nic do dodania, ale gdy nie ma już nic do zrobienia - Antoine de Saint-Exupéry
systempuntoout
7
Czy #LOC jest dobrą miarą jakości kodu? Mógłbym „zminimalizować” dowolny kod C lub C ++ i znacznie zmniejszyć liczbę wierszy, ale utrzymanie go byłoby koszmarem.
JBRWilkinson
8
@systempuntout - a potem była teoria Einstena „(Teoria naukowa) powinna być tak prosta, jak to możliwe, ale nie prostsza”
Jonathan Day
32
Nic nie działa szybciej, nie jest bardziej niezawodne lub wymaga mniej konserwacji niż kod, którego nie ma. „W razie wątpliwości rozwiń to!”
TMN
4
@JBRWilkinson: Powiedziałbym, że istnieje „słaby punkt” dotyczący zwięzłości kodu. Ogólnie rzecz biorąc, krótszy jest lepszy, ale przychodzi moment, w którym kod może stać się zbyt zwięzły i nie można go łatwo odczytać u innego programisty.
GordonM,
131

Cytat Billa Gatesa wzdłuż linii mierzenia produktywności programisty liniami kodu jest jak mierzenie postępów budowy samolotów według wagi.

Chciałbym dodać, że wskaźnik LOC zachęca do używania zbyt długich języków i świadomie wymyśla koło, aby osiągnąć limit.

Kyralessa
źródło
30
Tak, to jest problem z każdym rodzajem danych. Gdy tylko użyjesz ich do oceny wydajności ludzi, zaczną grać w liczby.
5
Czy ktoś kiedykolwiek używał LOC jako miernika wydajności? Widziałem to tylko w przypadku takich rzeczy, jak „o błędzie projektu, o którym tutaj mówimy?”
Michael Borgwardt
5
@Michael: tak. Niestety tak.
Michael Petrotta
4
czy mówimy o tym samym Billu G., który ma firmę, która według tej metafory wytwarza 10000 dżetów GTON? :)
Daniel Mošmondor
37
Programista, który napisał kod dla komputerów pokładowych promu kosmicznego, powiedział mi, że musi wziąć pod uwagę ciężar oprogramowania! Oprogramowanie było prawdziwe (pieniądze za to zapłacono); było na promie; należy uwzględnić ciężar wszystkiego załadowanego na prom. Pierwszy przykład pomiaru wydajności programisty według wagi kodu. (Zero nie było dozwolone, więc podał 0,00001 grama i wszystko było zadowalające.)
Mark Lutton
118

Kiedy byłem w liceum - i tak, mieliśmy komputery w latach 70., choć musieliśmy je ze skór zwierzęcych przy użyciu kamiennych noży - jeden z nauczycieli matematyki przeprowadził konkurs programistyczny. Reguły były takie, że wygrywającym programem byłby ten, który wygenerował poprawne wyjście, i który miał najmniejszy iloczyn linii czasu wykonania kodu. Oznacza to, że jeśli twój program wziął, powiedz 100 linii kodu i działał przez 5 sekund, twój wynik wynosił 500. Jeśli ktoś inny napisał 90 linii kodu i biegł przez 6 sekund, jego wynik to 540. Niski wynik wygrywa, jak golf.

Uderzył mnie jako świetny system punktacji, nagradzający zarówno zwięzłość, jak i wydajność.

Ale zgłoszenie, które technicznie spełniało kryteria wygranej, zostało zdyskwalifikowane. Problem polegał na wydrukowaniu listy wszystkich liczb pierwszych mniejszych niż 100. Wpis zdyskwalifikowany wyglądał mniej więcej tak (większość uczniów używała wtedy języka BASIC):

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

Student, który napisał ten wpis, zauważył, że nie tylko był on krótki i bardzo wydajny, ale algorytm powinien być oczywisty dla każdego, kto ma choćby minimalną wiedzę na temat programowania, dzięki czemu program jest bardzo łatwy w utrzymaniu.

Sójka
źródło
10
Kolejny dowód na to, że liczenie linii kodu jest bardzo grywalnym miernikiem :-)
44
Ten program BASIC jest genialny! Szkoda, że ​​nauczyciel zdyskwalifikował program. W końcu tabele odnośników (do których program jest nieco podobny) zdecydowanie można znaleźć w programowaniu w świecie rzeczywistym.
Noctis Skytower
6
Mądry nauczyciel mógł zaakceptować ten program BASIC i wykorzystać go do podkreślenia znaczenia uzyskania prawa do SRS. Przypomina mi trenera baseballu, który był tak sfrustrowany swoim zespołem, że aby pokazać im, jak grać, wziął nietoperza, dostał trzy uderzenia z rzędu i żeby się nie prześcignął, krzyknął do swojego zespołu: „Widzisz! ***** grają. Teraz weź nietoperz i graj poprawnie! ”. Przypomina mi także osobę, która napisała: „kreacja widziała twórcę i zarumieniła się” i wygrała konkurs na esej na temat „wina”.
Nav
3
@Nav: Przypomina mi podobną historię, która zaczyna się w ten sam sposób. Następnie trener rzuca piłkę w powietrze, kołysze się i chybia. Wyrzuca go ponownie w powietrze, kołysze i chybia. Wyrzuca go w powietrze po raz trzeci, kołysze i chybia. Potem mówi zespołowi: „Zobacz, jak powinieneś się rzucać!” (Nie mam pojęcia, co ta historia może mieć wspólnego z tworzeniem oprogramowania).
Jay
13
Byłbym bardzo zdenerwowany, gdybym został z tego powodu zdyskwalifikowany. Problem deterministyczny zasługuje na deterministyczne rozwiązanie, prawda? Kiedy piszę aplikację „Hello World”, nie koduję jej, aby sprawdzić, czy poprawnie wpisuję „Hello”.
Kirk Broadhurst
34

Ma język w policzek. Jeśli kosztuje Cię N $ za średnią kodowaną linię, wówczas kodowanie „linii ujemnych” z pewnością wygrywa.

Oznacza to, jako praktyczna rada, że ​​mały kod, który wykonuje zadanie, jest znacznie lepszy niż duży kod, który robi to samo, a wszystkie inne rzeczy są równe.

Ira Baxter
źródło
2
Widzę, skąd pochodzisz, ale zwięzły, łatwy do zrozumienia kod o małych rozmiarach rzadko jest osiągany za jednym razem. Zwykle pisze to tak, aby działało (wiele linii), optymalizowało prędkość (nieco mniej linii) i optymalizowało konserwację / czytelność (jeszcze mniej linii). Rzeczywisty koszt przy długim zwrocie inwestycji to drugi i trzeci krok, dlatego często są one całkowicie pomijane. To tak, jakby „jest tanie, szybkie i dobre - możesz wybrać dwa”.
2
W rzeczywistości, edytor IME, optymalizacja pod kątem konserwacji / czytelności, może w rzeczywistości zwiększyć LOC, ponieważ przepisywanie kodu w celu uczynienia go bardziej samo-dokumentującym zwykle powoduje, że jest bardziej gadatliwy.
1
@Visage: „... wszystkie inne rzeczy są równe”.
Ira Baxter,
Chodzi mi o to, że wszystkie inne rzeczy nie mogą być równe zwięzłemu kodowi i pełnemu kodowi.
Tomas Narros,
Powodem, dla którego średnia linia kodu kosztuje $ N, jest to, że najpierw spędzasz czas na pisaniu Xlinii. Następnie przez kilka iteracji, redukując produkt końcowy o Ylinie. Tak więc (X-Y)pozostałe linie wydają się bardzo kosztowne, ponieważ rzeź refaktoryzacji odciąła cały cruft.
27

Pisanie tego samego programu w mniejszej ilości kodu jest celem każdego.

Jeśli program wziął 200 LOC do kodowania, a ja piszę w 150, napisałem -50 LOC. Więc napisałem negatywny kod.

LucaB
źródło
3
Ponadto pisanie mniej LOC oznacza, że ​​możesz popełnić mniej błędów i łatwo je wykryć
LucaB
3
Nie dotyczy to języka Haskell i innych języków, które można skompresować do przypadkowego szumu. :)
Macke
1
Jasne, nie chodziło mi o „kompresowanie kodu”, ale o pisanie wydajnych algorytmów, które są rzadsze w mniejszym LOC :) +1 za komentarz.
LucaB,
9

Odpowiedź Thilo jest prawdopodobnie najdokładniejsza z historycznego punktu widzenia, ale metafora „kodu ujemnego” może również obejmować wydajność i wykorzystanie pamięci - nagradzanie wysiłków w celu odroczenia wykonania lub przydzielenia czegoś, dopóki nie będzie ono faktycznie potrzebne.

Ta mentalność „odwlekania się z płaceniem” wytworzyła takie nieprzyzwoite aksjomaty, takie jak „nic nie robić jest zawsze szybsze niż robienie czegoś”, „najszybszy kod to kod, który nigdy się nie wykonuje”, i „jeśli możesz go odłożyć wystarczająco długo, może nigdy nie będziesz musiał tego robić ”(odnosząc się do odroczenia kosztownych operacji, dopóki nie będzie to faktycznie wymagane)

Jedną z technik realizacji negatywnego kodu jest podważenie wstępnych założeń i definicji problemu. Jeśli możesz przedefiniować domenę problemu / wejściową tak, że „lepki problem nr 3” jest kategorycznie niemożliwy, nie musisz tracić czasu ani kodu na zajmowanie się lepkim problemem nr 3. Wyeliminowałeś kod, optymalizując projekt.

dthorpe
źródło