Kildelinjer - Source lines of code

Kildelinjer med kode ( SLOC ), også kendt som kodelinjer ( LOC ), er en softwaremetrik, der bruges til at måle størrelsen på et computerprogram ved at tælle antallet af linjer i teksten til programmets kildekode . SLOC bruges typisk til at forudsige den indsats, der skal til for at udvikle et program, samt til at estimere programmeringsproduktivitet eller vedligeholdelsesevne, når softwaren er produceret.

Målemetoder

Mange nyttige sammenligninger involverer kun størrelsesordenen for kodelinjer i et projekt. At bruge kodelinjer til at sammenligne et projekt på 10.000 linjer med et projekt på 100.000 linjer er langt mere nyttigt, end når man sammenligner et projekt på 20.000 linjer med et projekt på 21.000 linjer. Selvom det kan diskuteres præcist, hvordan man måler kodelinjer, kan uoverensstemmelser i en størrelsesorden være klare indikatorer for softwarekompleksitet eller arbejdstimer .

Der er to hovedtyper af SLOC -foranstaltninger: fysisk SLOC (LOC) og logisk SLOC (LLOC). Specifikke definitioner af disse to målinger varierer, men den mest almindelige definition af fysisk SLOC er et antal linjer i teksten i programmets kildekode eksklusive kommentarlinjer.

Logisk SLOC forsøger at måle antallet af eksekverbare "udsagn", men deres specifikke definitioner er knyttet til bestemte computersprog (et enkelt logisk SLOC -mål for C -lignende programmeringssprog er antallet af sætningsterminerende semikolon). Det er meget lettere at oprette værktøjer, der måler fysisk SLOC, og fysiske SLOC -definitioner er lettere at forklare. Fysiske SLOC -foranstaltninger er imidlertid følsomme over for logisk irrelevant formatering og stilkonventioner, mens logisk SLOC er mindre følsom over for formatering og stilkonventioner. Imidlertid angives SLOC -foranstaltninger ofte uden at give deres definition, og logisk SLOC kan ofte være væsentligt forskellig fra fysisk SLOC.

Betragt dette stykke C -kode som et eksempel på den tvetydighed, der opstår, når SLOC bestemmes:

for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */

I dette eksempel har vi:

• 1 fysisk kodelinje (LOC),
• 2 logiske kodelinjer (LLOC) ( til sætning og printf -sætning),
• 1 kommentar linje.

Afhængigt af programmerings- og kodningsstandarderne kan ovenstående "linje" med kode skrives på mange separate linjer:

/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
    printf("hello");
}

I dette eksempel har vi:

• 4 fysiske kodelinjer (LOC): Skal anbringelse af seler arbejde estimeres?
• 2 logiske kodelinjer (LLOC): hvad med alt det arbejde, der skriver non-statement linjer?
• 1 kommentarlinje: værktøjer skal tegne al kode og kommentarer uanset kommentarplacering.

Selv de "logiske" og "fysiske" SLOC -værdier kan have et stort antal forskellige definitioner. Robert E. Park (mens han var på Software Engineering Institute ) og andre udviklede en ramme for at definere SLOC -værdier, så folk kunne omhyggeligt forklare og definere SLOC -målingen, der blev brugt i et projekt. For eksempel genbruger de fleste softwaresystemer kode, og det er vigtigt at bestemme hvilken (hvis nogen) genbrugskode, der skal medtages, når der rapporteres et mål.

Oprindelse

På det tidspunkt, hvor folk begyndte at bruge SLOC som en metric, var de mest almindeligt anvendte sprog, såsom FORTRAN og samlingssprog , linjeorienterede sprog. Disse sprog blev udviklet på det tidspunkt, hvor hulkort var den vigtigste form for dataindtastning til programmering. Et stanset kort repræsenterede normalt en kodelinje. Det var et diskret objekt, der let kunne tælles. Det var programmørens synlige output, så det var fornuftigt for ledere at tælle kodelinjer som en måling af en programmørs produktivitet, selv med henvisning til f.eks. " Kortbilleder ". I dag giver de mest almindeligt anvendte computersprog meget mere spillerum til formatering. Tekstlinjer er ikke længere begrænset til 80 eller 96 kolonner, og en tekstlinje svarer ikke længere nødvendigvis til en linje med kode.

Anvendelse af SLOC -foranstaltninger

SLOC -foranstaltninger er noget kontroversielle, især på den måde, at de undertiden misbruges. Eksperimenter har gentagne gange bekræftet, at indsatsen er stærkt korreleret med SLOC, det vil sige, at programmer med større SLOC -værdier tager mere tid at udvikle. Således kan SLOC være effektiv til at estimere indsatsen. Funktionaliteten er imidlertid mindre godt korreleret med SLOC: dygtige udviklere kan muligvis udvikle den samme funktionalitet med langt mindre kode, så et program med færre SLOC kan udvise mere funktionalitet end et andet lignende program. At tælle SLOC som produktivitetsmåling har sine forbehold, da en udvikler kun kan udvikle nogle få linjer og alligevel være langt mere produktiv med hensyn til funktionalitet end en udvikler, der ender med at oprette flere linjer (og generelt bruger mere kræfter). Gode ​​udviklere kan flette flere kodemoduler til et enkelt modul, hvilket forbedrer systemet, men ser ud til at have negativ produktivitet, fordi de fjerner kode. Desuden tyer uerfarne udviklere ofte til kodeduplikation , hvilket er stærkt modløs, da det er mere fejlbehæftet og dyrt at vedligeholde, men det resulterer i højere SLOC.

SLOC -tælling udviser yderligere nøjagtighedsproblemer ved sammenligning af programmer skrevet på forskellige sprog, medmindre justeringsfaktorer anvendes til normalisering af sprog. Forskellige edb -sprog balancerer korthed og klarhed på forskellige måder; som et ekstremt eksempel ville de fleste samlingssprog kræve hundredvis af linjer med kode for at udføre den samme opgave som et par tegn i APL . Det følgende eksempel viser en sammenligning af et "hej verden" -program, der er skrevet i C , og det samme program skrevet i COBOL - et sprog, der er kendt for at være særligt omfattende.

#include <stdio.h>

int main() {
    printf("\nHello world\n");
}

      identification division.
      program-id. hello .
      procedure division.
      display "hello world"
      goback .
      end program hello .

Et andet stadig mere almindeligt problem ved sammenligning af SLOC-metrics er forskellen mellem automatisk genereret og håndskrevet kode. Moderne softwareværktøjer har ofte mulighed for automatisk at generere enorme mængder kode med et par klik med en mus. For eksempel genererer grafiske brugergrænsefladebyggere automatisk alle kildekoden til et grafisk kontrolelement ved blot at trække et ikon ind på et arbejdsområde. Arbejdet med at oprette denne kode kan ikke med rimelighed sammenlignes med det arbejde, der er nødvendigt for f.eks. At skrive en enhedsdriver. På samme måde kunne en håndkodet brugerdefineret GUI-klasse let være mere krævende end en simpel enhedsdriver; derfor mangler ved denne metrik.

Der er flere omkostnings-, tidsplan- og indsatsestimeringsmodeller, der bruger SLOC som inputparameter, herunder den meget anvendte model Constructive Cost Model ( COCOMO ) af Barry Boehm et al., PRICE Systems True S og Galoraths SEER-SEM . Selvom disse modeller har vist god forudsigelseskraft, er de kun lige så gode som de estimater (især SLOC -estimaterne), som de får. Mange har anbefalet brug af funktionspunkter i stedet for SLOC som et mål for funktionalitet, men da funktionspunkter er stærkt korreleret med SLOC (og ikke kan måles automatisk) er dette ikke en universelt opfattelse.

Eksempel

Ifølge Vincent Maraia, de SLOC værdier for forskellige operativsystemer i Microsoft 's Windows NT produktlinie er som følger:

David A. Wheeler studerede Red Hat -distributionen af Linux -operativsystemet og rapporterede, at Red Hat Linux version 7.1 (udgivet april 2001) indeholdt over 30 millioner fysiske SLOC. Han ekstrapolerede også, at hvis det var blevet udviklet med konventionelle proprietære midler, ville det have krævet omkring 8.000 personår med udviklingsindsats og ville have kostet over 1 milliard dollar (i år 2000 amerikanske dollars).

En lignende undersøgelse blev senere foretaget af Debian GNU/Linux version 2.2 (også kendt som "kartoffel"); dette operativsystem blev oprindeligt udgivet i august 2000. Denne undersøgelse viste, at Debian GNU/Linux 2.2 inkluderede over 55 millioner SLOC, og hvis det blev udviklet på en konventionel proprietær måde, ville det have krævet 14.005 årsværk og kostet 1,9 mia. USD at udvikle. Senere kørsler af de anvendte værktøjer rapporterer, at den følgende version af Debian havde 104 millioner SLOC, og fra 2005 vil den nyeste version omfatte over 213 millioner SLOC.

Værktøj

Fordele

1. Anvendelsesområde for automatisering af tælling: Da kodelinje er en fysisk enhed, kan manuel optællingsindsats let elimineres ved at automatisere tælleprocessen. Små hjælpeprogrammer kan udvikles til at tælle LOC i et program. Et logisk koderegningsprogram, der er udviklet til et specifikt sprog, kan imidlertid ikke bruges til andre sprog på grund af de syntaktiske og strukturelle forskelle mellem sprog. Fysiske LOC -tællere er imidlertid blevet produceret, som tæller snesevis af sprog.
2. En intuitiv metrik: kodelinje fungerer som en intuitiv metrik til måling af softwarens størrelse, fordi den kan ses, og effekten af ​​den kan visualiseres. Funktionspunkter siges at være mere en objektiv metrik, som ikke kan forestilles som en fysisk enhed, den eksisterer kun i det logiske rum. På denne måde er LOC praktisk til at udtrykke størrelsen på software blandt programmører med lav erfaring.
3. Allestedsnærværende foranstaltning: LOC -foranstaltninger har eksisteret siden de tidligste dage med software. Som sådan kan det argumenteres for, at flere LOC -data er tilgængelige end nogen anden størrelsesmåling.

Ulemper

1. Manglende ansvarlighed: måling af kodeord lider af nogle grundlæggende problemer. Nogle mener, at det ikke er nyttigt at måle produktiviteten af ​​et projekt ved kun at bruge resultater fra kodningsfasen, der normalt kun tegner sig for 30% til 35% af den samlede indsats.
2. Manglende samhørighed med funktionalitet: selvom forsøg gentagne gange har bekræftet, at selvom indsats er stærkt korreleret med LOC, er funktionalitet mindre godt korreleret med LOC. Det vil sige, at dygtige udviklere muligvis kan udvikle den samme funktionalitet med langt mindre kode, så et program med mindre LOC kan udvise mere funktionalitet end et andet lignende program. Især LOC er et dårligt produktivitetsmål for enkeltpersoner, fordi en udvikler, der kun udvikler nogle få linjer, stadig kan være mere produktiv end en udvikler, der opretter flere kodelinjer - endnu mere: nogle gode refaktorer som "ekstraktmetode" at slippe af med redundant kode og holde den ren vil for det meste reducere kodelinjerne.
3. Negativ indvirkning på estimering: På grund af den kendsgerning, der er præsenteret under punkt #1, kan estimater baseret på kodelinjer gå galt galt, med al mulighed.
4. Udvikleroplevelse: implementering af en bestemt logik er forskellig baseret på udviklernes erfaringsniveau. Derfor varierer antallet af kodelinjer fra person til person. En erfaren udvikler implementerer muligvis visse funktioner i færre kodelinjer end en anden udvikler med relativt mindre erfaring gør, selvom de bruger det samme sprog.
5. Forskel i sprog: overvej to applikationer, der har samme funktionalitet (skærme, rapporter, databaser). En af applikationerne er skrevet i C ++ og den anden applikation er skrevet på et sprog som COBOL. Antallet af funktionspunkter ville være nøjagtig det samme, men aspekter af applikationen ville være forskellige. De kodelinjer, der er nødvendige for at udvikle applikationen, ville bestemt ikke være de samme. Som en konsekvens ville den krævede indsats for at udvikle applikationen være anderledes (timer pr. Funktionspunkt). I modsætning til kodelinjer vil antallet af funktionspunkter forblive konstant.
6. Fremkomsten af GUI -værktøjer: med fremkomsten af GUI-baserede programmeringssprog og værktøjer som Visual Basic , kan programmører skrive relativt lidt kode og opnå en høj grad af funktionalitet. For eksempel kan en bruger med et GUI-værktøj i stedet for at skrive et program til at oprette et vindue og tegne en knap bruge træk-og-slip og andre musoperationer til at placere komponenter på et arbejdsområde. Kode, der automatisk genereres af et GUI -værktøj, tages normalt ikke i betragtning ved brug af LOC -målemetoder. Dette resulterer i variation mellem sprog; den samme opgave, der kan udføres på en enkelt kodelinje (eller slet ingen kode) på et sprog, kan kræve flere kodelinjer på et andet.
7. Problemer med flere sprog: I dagens softwarescenario udvikles software ofte på mere end ét sprog. Meget ofte bruges et antal sprog afhængigt af kompleksiteten og kravene. Sporing og rapportering af produktivitet og fejlrater udgør et alvorligt problem i dette tilfælde, da fejl ikke kan tilskrives et bestemt sprog efter integration af systemet. Funktionspunkt skiller sig ud for at være det bedste mål for størrelse i dette tilfælde.
8. Manglende tællestandarder: der er ingen standarddefinition af, hvad en kodelinje er. Tæller kommentarer? Er datadeklarationer inkluderet? Hvad sker der, hvis en erklæring strækker sig over flere linjer? - Det er de spørgsmål, der ofte melder sig. Selvom organisationer som SEI og IEEE har offentliggjort nogle retningslinjer i et forsøg på at standardisere tælling, er det svært at omsætte disse i praksis især i lyset af, at nyere og nyere sprog introduceres hvert år.
9. Psykologi: en programmør, hvis produktivitet måles i kodelinjer, vil have et incitament til at skrive unødigt detaljeret kode. Jo mere ledelse der fokuserer på kodelinjer, jo mere incitament har programmereren til at udvide sin kode med unødvendig kompleksitet. Dette er uønsket, da øget kompleksitet kan føre til øgede omkostninger til vedligeholdelse og øget indsats, der kræves til fejlrettelse.

I PBS -dokumentaren Triumph of the Nerds kritiserede Microsofts chef Steve Ballmer brugen af ​​at tælle kodelinjer:

I IBM er der en religion i software, der siger, at du skal tælle K-LOC'er, og en K-LOC er tusind linjer kode. Hvor stort et projekt er det? Åh, det er et slags 10K-LOC projekt. Dette er en 20K-LOCer. Og dette er 50K-LOC'er. Og IBM ville gerne gøre det til en religion om, hvordan vi fik løn. Hvor mange penge tjente vi på OS/2 , hvor meget de gjorde. Hvor mange K-LOC'er lavede du? Og vi blev ved med at prøve at overbevise dem-hej, hvis vi har det-en udvikler har en god idé, og han kan få gjort noget i 4K-LOC'er i stedet for 20K-LOC'er, skal vi tjene færre penge? Fordi han har lavet noget mindre og hurtigere, mindre K-LOC. K-LOC'er, K-LOC'er, det er metodikken. Ugh! Alligevel får det altid min ryg til at krølle ved tanken om det hele.

Ifølge Computer History Museum fandt Apple -udvikleren Bill Atkinson i 1982 problemer med denne praksis:

Da Lisa -teamet pressede på for at færdiggøre deres software i 1982, begyndte projektledere at kræve, at programmører indsendte ugentlige formularer, der rapporterede om antallet af kodelinjer, de havde skrevet. Bill Atkinson syntes det var fjollet. I den uge, hvor han havde omskrevet QuickDraws regionberegningsrutiner til at være seks gange hurtigere og 2000 linjer kortere, satte han “-2000 ″ på formularen. Efter et par uger stoppede lederne med at bede ham om at udfylde formularen, og han fulgte med glæde.

Relaterede vilkår

• KLOC / k eɪ l ɒ k / KAY -lok : 1.000 linjer kode
  • KDLOC: 1.000 leverede kodelinjer
  • KSLOC: 1.000 kildekoder
• MLOC: 1.000.000 linjer kode
• GLOC: 1.000.000.000 linjer kode

Se også

• Estimering af softwareudviklingsindsats
• Estimering (projektledelse)
• Estimering af omkostninger inden for software engineering

Noter

Referencer

Yderligere læsning

• Li, Luo; Herbsleb, Jim; Shaw, Mary (maj 2005). Forudsigelse af feltdefektpriser ved hjælp af en kombineret tidsbaseret og metrisk baseret tilgang til et casestudie af OpenBSD (CMU-ISRI-05-125) . Carnegie-Mellon University.
• McGraw, Gary (marts – april 2003). "Fra bunden: DIMACS Software Security Workshop" . IEEE Sikkerhed og fortrolighed . 1 (2): 59–66. doi : 10.1109/MSECP.2003.1193213 .
• Park, Robert E .; et al. "Måling af softwarestørrelse: En ramme til tælling af kildesætninger" . Teknisk rapport CMU/SEI-92-TR-20 .

eksterne links

• Definitioner af Practical Source Lines of Code Resource Standard Metrics (RSM) definerer "effektive kodelinjer" som en realistisk kode -metrik uafhængig af programmeringsstil.
• Effektive kodelinjer eLOC -metrics til populær Open Source -software Linux Kernel 2.6.17, Firefox, Apache HTTPD, MySQL, PHP ved hjælp af RSM.
• Wheeler, David A. "SLOCCount" . Hentet 2003-08-12 .
• Wheeler, David A. (juni 2001). "Counting Source Lines of Code (SLOC)" . Hentet 2003-08-12 .
• Tanenbaum, Andrew S. Moderne operativsystemer (2. udgave). Prentice Hall. ISBN  0-13-092641-8 .
• Howard Dahdah (2007-01-24). "Tanenbaum skitserer sin vision for et bedstemorsikkert OS" . Arkiveret fra originalen 2007-01-27 . Hentet 2007-01-29 .
• CM Lott: Metrics indsamlingsværktøjer til C og C ++ kildekoden
• Folklore.org: Macintosh -historier: -2000 kodelinjer