Quelllinien des Codes (SLOC) sind eine metrische Software hat gepflegt, die Größe eines Softwareprogramms durch das Zählen der Zahl von Linien im Text des Quellcodes des Programms zu messen. SLOC wird normalerweise verwendet, um den Betrag der Anstrengung vorauszusagen, die erforderlich sein wird, ein Programm zu entwickeln, sowie Programmierproduktivität oder Haltbarkeit zu schätzen, sobald die Software erzeugt wird.

Maß-Methoden

Viele nützliche Vergleiche schließen nur die Größenordnung von Linien des Codes in einem Projekt ein. Softwareprojekte können sich zwischen 1 bis 100,000,000 oder mehr Linien des Codes ändern. Das Verwenden von Linien des Codes, um ein 10,000 Linienprojekt mit einem 100,000 Linienprojekt zu vergleichen, ist viel nützlicher als, wenn es ein 20,000 Linienprojekt mit einem 21,000 Linienprojekt vergleicht. Während es genau diskutabel ist, wie man Linien des Codes misst, können Diskrepanzen einer Größenordnung klare Hinweise der Softwarekompliziertheit oder Mann-Stunden sein.

Es gibt zwei Haupttypen von SLOC-Maßnahmen: physischer SLOC (LOKALE NUMMER) und logischer SLOC (LLOC). Spezifische Definitionen dieser zwei Maßnahmen ändern sich, aber die allgemeinste Definition von physischem SLOC ist eine Zählung von Linien im Text des Quellcodes des Programms einschließlich Anmerkungslinien. Leere Linien werden auch eingeschlossen, wenn die Linien des Codes in einer Abteilung aus mehr als 25 % leeren Linien nicht bestehen. In diesem Fall werden leere Linien über 25 % zu Linien des Codes nicht aufgezählt.

Logischer SLOC versucht, die Zahl von rechtskräftigen "Behauptungen" zu messen, aber ihre spezifischen Definitionen werden an spezifische Computersprachen gebunden (ein einfaches logisches SLOC-Maß für C ähnliche Programmiersprachen ist die Zahl von Behauptung begrenzenden Strichpunkten). Es ist viel leichter, Werkzeuge zu schaffen, die physischen SLOC messen, und physische SLOC Definitionen leichter sind zu erklären. Jedoch sind physische SLOC-Maßnahmen zur logisch irrelevanten Formatierung und Stil-Vereinbarung empfindlich, während logisch, ist SLOC zur Formatierung und Stil-Vereinbarung weniger empfindlich. Jedoch werden SLOC Maßnahmen häufig festgesetzt, ohne ihre Definition zu geben, und logischer SLOC kann häufig von physischem SLOC bedeutsam verschieden sein.

Betrachten Sie diesen Schnipsel des C-Codes als ein Beispiel der Zweideutigkeit als gestoßen, wenn Sie SLOC bestimmen:

für (ich = 0; ich

In diesem Beispiel haben wir:

• 1 Physische Linie des Codes (LOC)

• 2 Logische Linien des Codes (LLOC) (für die Behauptung und printf Behauptung)

• 1 Anmerkungslinie

Abhängig vom Programmierer und/oder den Codierstandards konnte die obengenannte "Linie des Codes" über viele getrennte Linien geschrieben werden:

/* Jetzt, wie viele Linien des Codes das sind? * /

für (ich = 0; ich In diesem Beispiel haben wir:

• 5 Physische Linien des Codes (LOC): Soll das Stellen der Arbeit der geschweiften Klammern geschätzt werden?

• 2 Logische Linie des Codes (LLOC): wie steht's mit der ganzen Arbeit, Nichtbehauptungslinien schreibend?

• 1 Anmerkungslinie: Werkzeuge müssen für den ganzen Code und Anmerkungen unabhängig vom Anmerkungsstellen verantwortlich sein.

Sogar die "logischen" und "physischen" SLOC-Werte können eine Vielzahl von unterschiedlichen Definitionen haben. Robert E. Park (während am Softwaretechnikinstitut) u. a. entwickelt ein Fachwerk, um SLOC-Werte zu definieren, Leuten zu ermöglichen, das in einem Projekt verwendete SLOC-Maß sorgfältig zu erklären und zu definieren. Zum Beispiel, der grösste Teil des Softwaresystemwiedergebrauch-Codes und Bestimmung, die (wenn irgendwelcher) wiederverwendeter Code, um einzuschließen, wichtig ist, wenn er ein Maß meldet.

Ursprünge

Zurzeit, dass Leute begonnen haben, SLOC als ein metrischer zu verwenden, waren die meistens verwendeten Sprachen, wie FORTRAN und Monteur, linienorientierte Sprachen. Diese Sprachen wurden entwickelt, wenn geschlagene Karten die Hauptform des Datenzugangs für die Programmierung waren. Eine geschlagene Karte hat gewöhnlich eine Linie des Codes vertreten. Es war ein getrennter Gegenstand, der leicht aufgezählt wurde. Es war die sichtbare Produktion des Programmierers, so hat es Sinn Betriebsleitern gehabt, Linien des Codes als ein Maß einer Produktivität eines Programmierers aufzuzählen, sogar sich auf wie "Karte-Images" beziehend. Heute erlauben die meistens verwendeten Computersprachen viel mehr Rückstand für die Formatierung. Textlinien werden auf 80 oder 96 Säulen nicht mehr beschränkt, und eine Linie des Textes entspricht nicht mehr notwendigerweise einer Linie des Codes.

Gebrauch von SLOC-Maßnahmen

SLOC Maßnahmen sind besonders in der Weise etwas umstritten, wie sie manchmal missbraucht werden. Experimente haben wiederholt bestätigt, dass Anstrengung mit SLOC hoch aufeinander bezogen wird, d. h. nehmen Programme mit größeren SLOC-Werten mehr Zeit, um sich zu entwickeln. So kann SLOC im Schätzen der Anstrengung sehr wirksam sein. Jedoch wird Funktionalität mit SLOC weniger gut aufeinander bezogen: Fachentwickler können im Stande sein, dieselbe Funktionalität mit viel weniger Code zu entwickeln, so kann ein Programm mit weniger SLOC mehr Funktionalität ausstellen als ein anderes ähnliches Programm. Insbesondere SLOC ist ein schlechtes Produktivitätsmaß von Personen, da ein Entwickler nur einige Linien entwickeln und noch in Bezug auf die Funktionalität viel produktiver sein kann als ein Entwickler, der damit endet, mehr Linien zu schaffen (und allgemein mehr Anstrengung auszugeben). Gute Entwickler können vielfache Codemodule in ein einzelnes Modul verschmelzen, das System verbessernd, das noch scheint, negative Produktivität zu haben, weil sie Code entfernen. Außerdem neigen besonders erfahrene Entwickler dazu, die schwierigsten Aufgaben zugeteilt zu werden, und können manchmal so "weniger produktiv" scheinen als andere Entwickler auf einer Aufgabe durch dieses Maß. Außerdem suchen unerfahrene Entwickler häufig auf, um Verdoppelung zu codieren, die hoch entmutigt wird, weil es für den Programmfehler anfälliger und kostspielig ist, um aufrechtzuerhalten, aber es läuft höher auf SLOC hinaus.

SLOC ist beim Vergleichen von auf verschiedenen Sprachen geschriebenen Programmen besonders unwirksam, wenn Anpassungsfaktoren nicht angewandt werden, um Sprachen zu normalisieren. Verschiedene Computersprachen erwägen Kürze und Klarheit unterschiedlich; als ein äußerstes Beispiel würden die meisten Zusammenbau-Sprachen verlangen, dass Hunderte von Linien des Codes dieselbe Aufgabe wie einige Charaktere in APL durchführen. Das folgende Beispiel zeigt einen Vergleich eines "hallo" Weltprogramms, das in C und demselben Programm geschrieben ist, das im COBOL - eine Sprache geschrieben ist, die bekannt ist, um besonders wortreich zu sein.

Ein anderer zunehmend häufiges Problem im Vergleichen der SLOC Metrik ist der Unterschied zwischen dem autoerzeugten und handschriftlichen Code. Moderne Softwarewerkzeuge haben häufig die Fähigkeit, enorme Beträge des Codes mit einigen Klicks einer Maus zu autoerzeugen. Zum Beispiel erzeugen GUI Baumeister automatisch den ganzen Quellcode für einen GUI-Gegenstand, indem einfach sie eine Ikone auf einen Arbeitsraum schleppen. Die am Schaffen dieses Codes beteiligte Arbeit kann nicht im Vergleich zur Arbeit vernünftig sein, die notwendig ist, um einem Gerät-Fahrer zum Beispiel zu schreiben. Aus dem gleichen Grunde konnte eine GUI handcodierte kundenspezifische Klasse leicht anspruchsvoller sein als ein einfacher Gerät-Fahrer; folglich der Fehler davon metrisch.

Es gibt mehrere Kosten, Liste und Anstrengungsbewertungsmodelle, die SLOC als ein Eingangsparameter, einschließlich des weit verwendeten Konstruktiven Kostenmodells (COCOMO) Reihe von Modellen durch Barry Boehm verwenden u. a. PREIS-Systeme Wahrer S und der HELLSEHER-SEM von Galorath. Während diese Modelle gute prophetische Macht gezeigt haben, sind sie nur so gut wie die Schätzungen (besonders die SLOC-Schätzungen) gefüttert zu ihnen. Viele haben den Gebrauch von Funktionspunkten statt SLOC als ein Maß der Funktionalität verteidigt, aber da Funktionspunkte zu SLOC hoch aufeinander bezogen werden (und nicht automatisch gemessen werden kann), ist das nicht eine allgemein gehabte Ansicht.

Beispiel

Gemäß Vincent Maraia sind die SLOC-Werte für verschiedene Betriebssysteme im Erzeugnis des Windows NT des Microsofts wie folgt:

David A. Wheeler hat den Roten Vertrieb von Hat der Linuxs Betriebssystem studiert und hat berichtet, dass Rote Version 7.1 von Hat Linux (veröffentlichter April 2001) mehr als 30 Millionen physische SLOC enthalten hat. Er hat auch das extrapoliert, hatte es gewesen entwickelt durch herkömmliche Eigentumsmittel, es hätte ungefähr 8,000 Arbeitsjahre des Entwicklungsaufwandes verlangt und hätte mehr als $ 1 Milliarde (das Jahr 2000 Dollars der Vereinigten Staaten) gekostet.

Eine ähnliche Studie wurde später aus der Version 2.2 von Debian Linux (auch bekannt als "Kartoffel") gemacht; diese Version von Linux wurde im August 2000 ursprünglich veröffentlicht. Diese Studie hat gefunden, dass Debian Linux 2.2 mehr als 55 Millionen SLOC eingeschlossen hat, und wenn entwickelt, auf eine herkömmliche Eigentumsweise 14,005 Arbeitsjahre verlangt und den US-Dollar von $ 1.9 Milliarden gekostet hätte, um sich zu entwickeln. Spätere Läufe der Werkzeuge haben Bericht verwendet, dass die folgende Ausgabe von Debian 104 Millionen SLOC hatte, und die neueste Ausgabe ist dabei, mehr als 213 Millionen SLOC einzuschließen.

Man kann Zahlen von Hauptbetriebssystemen finden (die verschiedenen Windows-Versionen sind in einem Tisch oben präsentiert worden)

Beziehung mit Sicherheitsschulden

Mehrere Experten haben eine Beziehung zwischen der Zahl von Linien des Codes in einem Programm und der Zahl von Programmfehlern gefordert, die es enthält. Diese Beziehung ist nicht einfach, da sich die Zahl von Fehlern pro Linie des Codes außerordentlich gemäß der Sprache verwendet, der Typ von Qualitätssicherungsprozessen und das Niveau der Prüfung ändert, aber es scheint wirklich zu bestehen. Noch wichtiger die Zahl von Programmfehlern in einem Programm ist direkt mit der Zahl von Sicherheitsschulden verbunden gewesen, die wahrscheinlich im Programm gefunden werden.

Das hat mehrere wichtige Implikationen für die Systemsicherheit gehabt, und diese können widerspiegelt im Betriebssystemdesign gesehen werden. Erstens werden kompliziertere Systeme wahrscheinlich einfach wegen der größeren Zahl von Linien des Codes unsicherer sein musste sie entwickeln. Deshalb hat sich Sicherheit konzentriert Systeme wie OpenBSD wachsen viel langsamer als andere Systeme wie Windows und Linux. Eine zweite Idee, die in OpenBSD, Windows und vielen Varianten von Linux aufgenommen ist, besteht darin, dass das Trennen des Codes in verschiedene Abteilungen, die mit verschiedenen Sicherheitsumgebungen laufen (mit oder ohne spezielle Vorzüge, zum Beispiel) sicherstellt, dass der grösste Teil der Sicherheit kritische Segmente klein und sorgfältig revidiert ist.

Dienstprogramm

Vorteile

1. Spielraum für die Automation des Zählens: Da die Linie des Codes eine physische Entität ist; manuelle zählende Anstrengung kann durch das Automatisieren des Zählen-Prozesses leicht beseitigt werden. Kleine Dienstprogramme können entwickelt werden, für die LOKALE NUMMER in einem Programm aufzuzählen. Jedoch kann ein Code, für eine spezifische Sprache entwickeltes Dienstprogramm aufzählend, nicht für andere Sprachen wegen der syntaktischen und strukturellen Unterschiede unter Sprachen verwendet werden.
2. Ein Intuitiver Metrischer: Die Linie des Codes dient als ein intuitiver metrischer, für die Größe der Software zu messen, weil es gesehen werden kann und die Wirkung davon vergegenwärtigt werden kann. Wie man sagt, sind Funktionspunkte mehr von einem metrischen Ziel, der als seiend eine physische Entität nicht vorgestellt werden kann, besteht es nur im logischen Raum. Auf diese Weise geht LOKALE NUMMER handlich ein, um die Größe der Software unter Programmierern mit niedrigen Stufen der Erfahrung auszudrücken.

Nachteile

1. Fehlen Sie von der Verantwortlichkeit: Linien des Codemaßes leiden unter einigen grundsätzlichen Problemen. Einige denken, dass es nicht nützlich ist zu messen, ergibt sich die Produktivität eines Projektes damit nur aus der Codierphase, die gewöhnlich für nur 30 % bis 35 % der gesamten Anstrengung verantwortlich ist.
2. Fehlen Sie von der Kohäsion mit der Funktionalität: Obwohl Experimente wiederholt bestätigt haben, dass Anstrengung mit der LOKALEN NUMMER hoch aufeinander bezogen wird, wird Funktionalität mit der LOKALEN NUMMER weniger gut aufeinander bezogen. D. h. Fachentwickler können im Stande sein, dieselbe Funktionalität mit viel weniger Code zu entwickeln, so kann ein Programm mit weniger LOKALER NUMMER mehr Funktionalität ausstellen als ein anderes ähnliches Programm. Insbesondere LOKALE NUMMER ist ein schlechtes Produktivitätsmaß von Personen, weil ein Entwickler, der nur einige Linien entwickelt, noch produktiver sein kann als ein Entwickler, der mehr Linien des Codes - noch mehr schafft: Ein gutes Wiederfactoring wie "Extrakt-Methode", um den überflüssigen Code loszuwerden und es sauber zu halten, wird größtenteils die Linien des Codes reduzieren.
3. Nachteiliger Einfluss auf Bewertung: Wegen der Tatsache, die unter dem Punkt #1 präsentiert ist, können auf Linien des Codes gestützte Schätzungen in der ganzen Möglichkeit nachteilig schief gehen.
4. Die Erfahrung des Entwicklers: Die Durchführung einer spezifischen Logik unterscheidet sich gestützt auf dem Niveau der Erfahrung des Entwicklers. Folglich unterscheidet sich die Zahl von Linien des Codes von der Person der Person. Ein erfahrener Entwickler kann bestimmte Funktionalität in weniger Linien des Codes durchführen, als ein anderer Entwickler von relativ weniger Erfahrung tut, obwohl sie dieselbe Sprache verwenden.
5. Unterschied in Sprachen: Denken Sie zwei Anwendungen, die dieselbe Funktionalität (Schirme, Berichte, Datenbanken) zur Verfügung stellen. Eine der Anwendungen wird in C ++ und die andere Anwendung geschrieben, die auf einer Sprache wie COBOL geschrieben ist. Die Zahl von Funktionspunkten würde genau dasselbe sein, aber Aspekte der Anwendung würden verschieden sein. Die Linien des Codes mussten sich entwickeln die Anwendung würde nicht sicher dasselbe sein. Demzufolge würde der Betrag der Anstrengung, die erforderlich ist, die Anwendung zu entwickeln (Stunden pro Funktionspunkt) verschieden sein. Verschieden von Linien des Codes wird die Zahl von Funktionspunkten unveränderlich bleiben.
6. Advent von GUI Werkzeugen: Mit dem Advent von GUI-basierten Programmiersprachen und Werkzeugen solcher als Visuell Grundlegend können Programmierer relativ wenig Code schreiben und hohe Niveaus der Funktionalität erreichen. Zum Beispiel, anstatt ein Programm zu schreiben, um ein Fenster zu schaffen und einen Knopf zu ziehen, kann ein Benutzer mit einem GUI Werkzeug Schinderei-Und-Fall und andere Maus-Operationen verwenden, um Bestandteile auf einem Arbeitsraum zu legen. Code, der durch ein GUI Werkzeug automatisch erzeugt wird, wird nicht gewöhnlich in Betracht gezogen, wenn man LOKAL Methoden des Maßes verwendet. Das läuft auf Schwankung zwischen Sprachen hinaus; dieselbe Aufgabe, die in einer einzelnen Linie des Codes (oder keines Codes überhaupt) auf einer Sprache getan werden kann, kann mehrere Linien des Codes in einem anderen verlangen.
7. Probleme mit Vielfachen Sprachen: Im Heutigen Softwaredrehbuch wird Software häufig auf mehr als einer Sprache entwickelt. Sehr häufig werden mehrere Sprachen abhängig von der Kompliziertheit und den Voraussetzungen verwendet. Das Verfolgen und das Melden Produktivitäts- und Defekt-Raten werfen ein ernstes Problem in diesem Fall auf, da Defekte einer besonderen auf die Integration des Systems nachfolgenden Sprache nicht zugeschrieben werden können. Funktionspunkt tritt hervor, um das beste Maß der Größe in diesem Fall zu sein.
8. Fehlen Sie vom Aufzählen von Standards: Es gibt keine Standarddefinition dessen, wie eine Linie des Codes ist. Zählen Anmerkungen? Werden Datenbehauptungen eingeschlossen? Was geschieht, wenn sich eine Behauptung über mehrere Linien ausstreckt? - Das sind die Fragen, die häufig entstehen. Obwohl Organisationen wie SEI und IEEE einige Richtlinien in einem Versuch veröffentlicht haben, das Zählen zu standardisieren, ist es schwierig, diese besonders angesichts neuerer und neuerer Sprachen in die Praxis umzusetzen, die jedes Jahr einführen werden.
9. Psychologie: Ein Programmierer, dessen Produktivität in Linien des Codes gemessen wird, wird einen Ansporn haben, unnötigerweise wortreichen Code zu schreiben. Je sich mehr Management auf Linien des Codes konzentriert, desto anspornender der Programmierer seinen Code mit der nicht benötigten Kompliziertheit ausbreiten muss. Das ist unerwünscht, da vergrößerte Kompliziertheit zu vergrößerten Unterhaltungskosten und vergrößerter für das Programmfehler-Befestigen erforderlicher Anstrengung führen kann.

Im PBS Dokumentartriumph der Trottel hat Manager von Microsoft Steve Ballmer den Gebrauch des Zählens von Linien des Codes kritisiert:

In IBM gibt es eine Religion in der Software, die sagt, dass Sie K-LOCs aufzählen müssen, und ein K-LOC eintausend Linien des Codes ist. Wie groß ein Projekt es ist? Oh, es ist Sorte eines 10K-LOKALN Projektes. Das ist ein 20K-LOCer. Und das ist 50K-LOCs. Und IBM hat zur Sorte dessen gewollt machen es die Religion darüber, wie wir bezahlt wurden. Wie viel Geld wir uns OS/2 davongemacht haben, wie viel sie getan haben. Wie vieler K-LOCs taten Sie? Und wir setzten fort zu versuchen, sie - he zu überzeugen, wenn wir haben - hat ein Entwickler eine gute Idee, und er kann etwas in 4K-LOCs statt 20K-LOCs tun lassen, sollten wir weniger Geld machen? Weil er etwas kleiner und schneller, weniger K-LOC gemacht hat. K-LOCs, K-LOCs, ist es die Methodik. Hu! Irgendwie macht das immer meinen Rücken, gerade sich am Gedanken an alles zu kräuseln.

Zusammenhängende Begriffe

• KLOC : 1,000 Linien des Codes
• KDLOC: 1,000 gelieferte Linien des Codes
• KSLOC: 1,000 Quelllinien des Codes
• MLOC: 1,000,000 Linien des Codes
• GLOC: 1,000,000,000 Linien des Codes

Siehe auch

• Softwareentwicklungsaufwand-Bewertung
• Bewertung (planen Management)
• Vergleich der Entwicklungsbewertungssoftware

Weiterführende Literatur

Links

• Definitionen von Praktischen Quelllinien des Codes Resource Standard Metrics (RSM) definiert "wirksame Linien des Codes" als ein realistics, codieren metrischen Unabhängigen, Stil zu programmieren.
• Wirksame Linien des Codes eLOC Metrik für die populäre Software des Open Sources Linux Kern 2.6.17, Firefox, Apachen-HTTPD, MySQL, PHP, der RSM verwendet.
• Tanenbaum, Andrew S. Modern Operating Systems (2. Hrsg.). Prentice Hall. Internationale Standardbuchnummer 0-13-092641-8.
• C. M. Lott: Metrik-Sammlungswerkzeuge für C und C ++ Quellcode
• Folklore.org: Geschichten von Macintosh:-2000 Linien des Codes