Källkodsrader

Källkodsrader ( SLOC ), även känd som kodrader ( LOC ), är ett programvarumått som används för att mäta storleken på ett datorprogram genom att räkna antalet rader i texten i programmets källkod . SLOC används vanligtvis för att förutsäga hur mycket ansträngning som kommer att krävas för att utveckla ett program, samt för att uppskatta programmeringsproduktivitet eller underhållsbarhet när programvaran väl har producerats.

Mätmetoder

Många användbara jämförelser involverar endast storleksordningen på kodrader i ett projekt. Att använda kodrader för att jämföra ett projekt på 10 000 rader med ett projekt på 100 000 rader är mycket mer användbart än när man jämför ett projekt på 20 000 rader med ett projekt på 21 000 rader. Även om det är diskutabelt exakt hur man mäter kodrader, kan avvikelser i en storleksordning vara tydliga indikatorer på mjukvarans komplexitet eller mantimmar .

Det finns två huvudtyper av SLOC-mått: fysisk SLOC (LOC) och logisk SLOC (LLOC). Specifika definitioner av dessa två åtgärder varierar, men den vanligaste definitionen av fysisk SLOC är ett antal rader i texten i programmets källkod exklusive kommentarrader.

Logisk SLOC försöker mäta antalet körbara "påståenden", men deras specifika definitioner är knutna till specifika datorspråk (ett enkelt logiskt SLOC-mått för C -liknande programmeringsspråk är antalet satsavslutande semikolon). Det är mycket lättare att skapa verktyg som mäter fysisk SLOC, och fysiska SLOC-definitioner är lättare att förklara. Fysiska SLOC-mått är dock mer känsliga för logiskt irrelevanta formaterings- och stilkonventioner än logiska SLOC. SLOC-mått anges dock ofta utan att deras definition anges, och logisk SLOC kan ofta skilja sig väsentligt från fysisk SLOC.

Betrakta detta fragment av C-kod som ett exempel på tvetydigheten som uppstår när SLOC bestäms:

   0       för  (  i  =  ;  i  <  100  ;  i  ++  )  printf  (  "hej" )  ;  /* Hur många rader kod är detta? */

I det här exemplet har vi:

  • 1 fysisk kodrad (LOC),
  • 2 logiska rader kod (LLOC) ( för uttalande och printf -sats),
  • 1 kommentarsrad.

Beroende på programmerare och kodningsstandarder kan ovanstående "rad" kod skrivas på många separata rader:


   0    

    
 /* Hur många rader kod är det här? */   for  (  i  =  ;  i  <  100  ;  i  ++  )  {  printf  (  "hej"  );  }

I det här exemplet har vi:

  • 4 fysiska kodrader (LOC): är det något att uppskatta att placera hängslen?
  • 2 logiska rader kod (LLOC): hur är det med allt arbete med att skriva rader utan påstående?
  • 1 kommentarrad: verktyg måste ta hänsyn till all kod och kommentarer oavsett placering av kommentarer.

Även de "logiska" och "fysiska" SLOC-värdena kan ha ett stort antal olika definitioner. Robert E. Park (medan han arbetade på Software Engineering Institute ) och andra utvecklade ett ramverk för att definiera SLOC-värden, för att göra det möjligt för människor att noggrant förklara och definiera SLOC-måttet som används i ett projekt. Till exempel återanvänder de flesta programvarusystem kod, och att bestämma vilken (om någon) återanvänd kod som ska inkluderas är viktigt när en åtgärd rapporteras.

Ursprung

Vid den tidpunkt då folk började använda SLOC som ett mått, var de vanligaste språken, som FORTRAN och assemblerspråk , linjeorienterade språk. Dessa språk utvecklades vid den tidpunkt då hålkort var den huvudsakliga formen för datainmatning för programmering. Ett hålkort representerade vanligtvis en kodrad. Det var ett diskret föremål som var lätt att räkna. Det var programmerarens synliga utdata, så det var vettigt för chefer att räkna rader kod som ett mått på en programmerares produktivitet, till och med med hänvisning till som " kortbilder ". Idag tillåter de vanligaste datorspråken mycket mer spelrum för formatering. Textrader är inte längre begränsade till 80 eller 96 kolumner, och en textrad motsvarar inte längre nödvändigtvis en rad kod.

Användning av SLOC-mått

SLOC-åtgärder är något kontroversiella, särskilt på det sättet att de ibland missbrukas. Experiment har upprepade gånger bekräftat att ansträngning är starkt korrelerad med SLOC [ citation needed ] , det vill säga program med större SLOC-värden tar längre tid att utveckla. Således kan SLOC vara effektivt för att uppskatta ansträngning. Funktionalitet är dock mindre bra korrelerad med SLOC: skickliga utvecklare kanske kan utveckla samma funktionalitet med mycket mindre kod, så ett program med färre SLOC kan uppvisa mer funktionalitet än ett annat liknande program. Att räkna SLOC som produktivitetsmått har sina förbehåll, eftersom en utvecklare bara kan utveckla ett fåtal rader och ändå vara mycket mer produktiv när det gäller funktionalitet än en utvecklare som i slutändan skapar fler linjer (och i allmänhet spenderar mer ansträngning). Bra utvecklare kan slå samman flera kodmoduler till en enda modul, vilket förbättrar systemet och ändå verkar ha negativ produktivitet eftersom de tar bort kod. Dessutom tar oerfarna utvecklare ofta till kodduplicering , vilket är mycket avskräckt eftersom det är mer felbenäget och kostsamt att underhålla, men det resulterar i högre SLOC.

SLOC-räkning uppvisar ytterligare noggrannhetsproblem vid jämförelse av program skrivna på olika språk om inte justeringsfaktorer tillämpas för att normalisera språk. Olika datorspråk balanserar korthet och tydlighet på olika sätt; som ett extremt exempel skulle de flesta assemblerspråk kräva hundratals rader kod för att utföra samma uppgift som några få tecken i APL . Följande exempel visar en jämförelse av ett "hej världen"-program skrivet i BASIC , C och COBOL (ett språk känt för att vara särskilt mångsidigt).

GRUNDLÄGGANDE C COBOL 
  SKRIV UT  "hej världen" 

 

  
    
 #include  <stdio.h>  int  main  ()  {  printf  (  "hej världen  \n  "  );  } 

       
        
       
      
      
          identifieringsavdelning  .  _  program-id  .  hej  .  förfarandeuppdelning  .  _  visa  "hej världen"  goback  .  avsluta  programmet  hej  .

Kodrader: 1 (inget blanksteg)
Kodrader: 3 (exklusive blanksteg)
Kodrader: 6 (exklusive blanksteg)

Ett annat allt vanligare problem vid jämförelse av SLOC-mått är skillnaden mellan autogenererad och handskriven kod. Moderna mjukvaruverktyg har ofta förmågan att automatiskt generera enorma mängder kod med några få musklick. Till exempel grafiska användargränssnittsbyggare automatiskt all källkod för ett grafiskt kontrollelement genom att helt enkelt dra en ikon till en arbetsyta. Arbetet med att skapa den här koden kan inte rimligen jämföras med det arbete som krävs för att skriva en enhetsdrivrutin, till exempel. På samma sätt kan en handkodad anpassad GUI-klass lätt vara mer krävande än en enkel enhetsdrivrutin; därav bristen i detta mått.

Det finns flera kostnads-, schema- och ansträngningsuppskattningsmodeller som använder SLOC som en ingångsparameter, inklusive den mycket använda serien Constructive Cost Model ( COCOMO ) av modeller av Barry Boehm et al., PRICE Systems True S och Galoraths SEER-SEM . Även om dessa modeller har visat god prediktiv kraft, är de bara så bra som uppskattningarna (särskilt SLOC-uppskattningarna) som de har fått. Många har förespråkat användningen av funktionspunkter istället för SLOC som ett mått på funktionalitet, men eftersom funktionspunkter är starkt korrelerade till SLOC (och inte kan mätas automatiskt) är detta inte en universell uppfattning.

Exempel

Enligt Vincent Maraia är SLOC-värdena för olika operativsystem i Microsofts Windows NT- produktlinje följande:

År Operativ system SLOC (miljoner)
1993 Windows NT 3.1 4–5
1994 Windows NT 3.5 7–8
1996 Windows NT 4.0 11–12
2000 Windows 2000 mer än 29
2001 Windows XP 45
2003 Windows Server 2003 50

David A. Wheeler studerade Red Hat- distributionen av operativsystemet Linux och rapporterade att Red Hat Linux version 7.1 (släpptes i april 2001) innehöll över 30 miljoner fysiska SLOC. Han extrapolerade också att om det hade utvecklats på konventionellt sätt, skulle det ha krävt cirka 8 000 personår av utvecklingsinsatser och skulle ha kostat över 1 miljard dollar (år 2000 US-dollar).

En liknande studie gjordes senare av Debian GNU/Linux version 2.2 (även känd som "Potatis"); detta operativsystem släpptes ursprungligen i augusti 2000. Denna studie fann att Debian GNU/Linux 2.2 inkluderade över 55 miljoner SLOC, och om det utvecklats på ett konventionellt proprietärt sätt skulle det ha krävt 14 005 årsverken och kostat 1,9 miljarder USD att utveckla. Senare körningar av de använda verktygen rapporterar att följande utgåva av Debian hade 104 miljoner SLOC, och från och med år 2005 kommer den senaste utgåvan att inkludera över 213 miljoner SLOC.

År Operativ system SLOC (miljoner)
2000 Debian 2.2 55–59
2002 Debian 3.0 104
2005 Debian 3.1 215
2007 Debian 4.0 283
2009 Debian 5.0 324
2012 Debian 7.0 419
2009 OpenSolaris 9.7
FreeBSD 8.8
2005 Mac OS X 10.4 86
1991 Linuxkärna 0.01 0,010239
2001 Linuxkärna 2.4.2 2.4
2003 Linuxkärna 2.6.0 5.2
2009 Linuxkärna 2.6.29 11.0
2009 Linuxkärna 2.6.32 12.6
2010 Linuxkärna 2.6.35 13.5
2012 Linuxkärna 3.6 15.9
2015-06-30 Linux-kärnan före 4.2 20.2

Verktyg

Fördelar

  1. Omfattning för automatisering av räkning: eftersom kodraden är en fysisk enhet, kan manuell räkning lätt elimineras genom att automatisera räkneprocessen. Små verktyg kan utvecklas för att räkna LOC i ett program. Ett logiskt kodräkningsverktyg utvecklat för ett specifikt språk kan dock inte användas för andra språk på grund av de syntaktiska och strukturella skillnaderna mellan språk. Fysiska LOC-räknare har dock tagits fram som räknar dussintals språk.
  2. Ett intuitivt mått: kodraden fungerar som ett intuitivt mått för att mäta storleken på programvaran eftersom den kan ses och effekten av den kan visualiseras. Funktionspunkter sägs vara mer av ett objektivt mått som inte kan föreställas som en fysisk enhet, den existerar bara i det logiska rummet. På så sätt kommer LOC väl till pass för att uttrycka storleken på programvaran bland programmerare med låg erfarenhet.
  3. Ubiquitous mått: LOC-mått har funnits sedan mjukvarans tidigaste dagar. Som sådan kan det argumenteras att mer LOC-data är tillgänglig än något annat storleksmått.

Nackdelar

  1. Brist på ansvarighet: kodradsmåttet lider av några grundläggande problem. Vissa [ vem? ] tror att det inte är användbart att mäta produktiviteten i ett projekt med endast resultat från kodningsfasen, som vanligtvis bara står för 30 % till 35 % av den totala ansträngningen. [ citat behövs ]
  2. Brist på sammanhållning med funktionalitet: genom experiment [ av vem? ] har upprepade gånger bekräftat att även om ansträngning är starkt korrelerad med LOC, är funktionalitet mindre bra korrelerad med LOC. Det vill säga, skickliga utvecklare kan kanske utveckla samma funktionalitet med mycket mindre kod, så ett program med mindre LOC kan uppvisa mer funktionalitet än ett annat liknande program. I synnerhet är LOC ett dåligt produktivitetsmått på individer, eftersom en utvecklare som bara utvecklar ett fåtal rader fortfarande kan vara mer produktiv än en utvecklare som skapar fler rader kod – ännu mer: någon bra refactoring som "extraheringsmetod" för att bli av med redundant kod och hålla den ren kommer för det mesta att minska kodraderna.
  3. Negativ inverkan på uppskattning: på grund av det faktum som presenteras under punkt #1, kan uppskattningar baserade på kodrader gå fel, med alla möjligheter.
  4. Utvecklarens erfarenhet: implementeringen av en specifik logik skiljer sig beroende på utvecklarens erfarenhetsnivå. Därför skiljer sig antalet kodrader från person till person. En erfaren utvecklare kan implementera viss funktionalitet i färre rader kod än en annan utvecklare med relativt mindre erfarenhet gör, även om de använder samma språk.
  5. Skillnad i språk: överväg två applikationer som tillhandahåller samma funktionalitet (skärmar, rapporter, databaser). En av applikationerna är skriven i C++ och den andra applikationen skriven på ett språk som COBOL. Antalet funktionspunkter skulle vara exakt detsamma, men aspekter av applikationen skulle vara olika. Kodraderna som behövs för att utveckla applikationen skulle verkligen inte vara desamma. Som en konsekvens skulle mängden ansträngning som krävs för att utveckla applikationen vara olika (timmar per funktionspunkt). Till skillnad från kodrader kommer antalet funktionspunkter att förbli konstant.
  6. Tillkomsten av GUI -verktyg: med tillkomsten av GUI-baserade programmeringsspråk och verktyg som Visual Basic , kan programmerare skriva relativt lite kod och uppnå höga nivåer av funktionalitet. Till exempel, istället för att skriva ett program för att skapa ett fönster och rita en knapp, kan en användare med ett GUI-verktyg använda dra-och-släpp och andra musoperationer för att placera komponenter på en arbetsyta. Kod som genereras automatiskt av ett GUI-verktyg tas vanligtvis inte i beaktande när man använder LOC-mätmetoder. Detta resulterar i variation mellan språk; samma uppgift som kan göras på en enda kodrad (eller ingen kod alls) på ett språk kan kräva flera rader kod på ett annat.
  7. Problem med flera språk: i dagens mjukvaruscenario utvecklas mjukvara ofta på mer än ett språk. Mycket ofta används ett antal språk beroende på komplexiteten och kraven. Spårning och rapportering av produktivitet och defektfrekvenser utgör ett allvarligt problem i detta fall, eftersom defekter inte kan hänföras till ett visst språk efter integrationen av systemet. Funktionspunkt framstår som det bästa måttet på storlek i detta fall.
  8. Brist på räknestandarder: det finns ingen standarddefinition av vad en kodrad är. Räknas kommentarer? Ingår datadeklarationer? Vad händer om ett påstående sträcker sig över flera rader? – Det är frågor som ofta dyker upp. Även om organisationer som SEI och IEEE har publicerat några riktlinjer i ett försök att standardisera räkningen, är det svårt att omsätta dessa i praktiken, särskilt med tanke på att nyare och nyare språk introduceras varje år.
  9. Psykologi: en programmerare vars produktivitet mäts i kodrader kommer att ha ett incitament att skriva onödigt utförlig kod. Ju mer ledningen fokuserar på kodrader, desto mer incitament har programmeraren att utöka sin kod med onödig komplexitet. Detta är inte önskvärt, eftersom ökad komplexitet kan leda till ökade underhållskostnader och ökad ansträngning som krävs för att fixa fel.

I PBS- dokumentären Triumph of the Nerds kritiserade Microsoft-chefen Steve Ballmer användningen av att räkna rader med kod:

I IBM finns det en religion inom mjukvara som säger att du måste räkna K-LOC, och en K-LOC är tusen rader kod. Hur stort projekt är det? Åh, det är typ ett 10K-LOC-projekt. Detta är en 20K-LOCer. Och det här är 50K-LOCs. Och IBM ville liksom göra det till religionen om hur vi fick betalt. Hur mycket pengar vi tjänade på OS/2 , hur mycket de gjorde. Hur många K-LOCs gjorde du? Och vi fortsatte att försöka övertyga dem – hej, om vi har – en utvecklare har en bra idé och han kan få något gjort i 4K-LOCs istället för 20K-LOCs, borde vi tjäna mindre pengar? Eftersom han har gjort något mindre och snabbare, mindre K-LOC. K-LOC, K-LOC, det är metoden. usch! Hur som helst, det får alltid min rygg att krypa ihop vid tanken på det hela.

Enligt Computer History Museum hittade Apple-utvecklaren Bill Atkinson 1982 problem med denna praxis:

När Lisa-teamet pressade på för att färdigställa sin programvara 1982 började projektledare kräva att programmerare skickade in veckoformulär som rapporterade antalet rader kod de hade skrivit. Bill Atkinson tyckte det var dumt. För veckan då han hade skrivit om QuickDraws regionberäkningsrutiner för att vara sex gånger snabbare och 2000 rader kortare, satte han "-2000" på formuläret. Efter ytterligare några veckor slutade cheferna att be honom fylla i formuläret, och han följde med glädje.

Relaterade termer

  • KLOC / ˈ k eɪ l ɒ k / KAY -lok : 1 000 rader kod
    • KDLOC: 1 000 levererade kodrader
    • KSLOC: 1 000 källrader kod
  • MLOC: 1 000 000 rader kod
  • GLOC: 1 000 000 000 rader kod

Se även

Anteckningar

  1. ^ Möjligen inklusive hela iLife-sviten, inte bara operativsystemet och vanligtvis medföljande applikationer.

Vidare läsning

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Source_lines_of_code&oldid=1131790234 "