Vu Nguyen, Sophia Deeds-Rubin, Thomas Tan
Center for Systems and Software Engineering
CSSE COCOMO Forum 2007
(c) USC-CSSE 1

• Introduction
– Overview
– Physical vs. Logical
– Who needs SLOC
– Existing SLOC definitions
• Problems With SLOC Counting Practice
– Limitations
– Tool Mismatch
• Counting Standard
– What to count
– How to count
– Example
• Conclusions
(c) USC-CSSE 2

• Traditional and popular sizing metric for software
• Key input for many major cost estimation tool such as COCOMO,
SEER, and SLIM
• Direct results of programming work
• Two types of lines to count
– Physical SLOC
– Logical SLOC
(c) USC-CSSE 3

• Language-independent
• Easy to count
• Dependent on style and format of language
• Inconsistent across organizations, projects, and individual programmers
(c) USC-CSSE 4

• Independent of style and format
• Strong correlation with effort
• Recommended as standard size input for estimation models e.g. COCOMO
• Lacks precise definitions
• Depends on language specifics
• Hard to count
– Simply counts lines end with semicolon is not the way to do it
(c) USC-CSSE 5

• Software Metrics
• Estimation tools
– COCOMO
– SLIM
– SEER – SEM
– PRICE-S
• Quality Measurements
(c) USC-CSSE 6

• Introduced by Dr. Boehm as Delivered
Source Instructions (DSI) or Delivered
Source Line of Code (DSLOC)
• IEEE provided definitions and attributes of SLOC sizing metrics
• SEI extended SLOC metrics into a counting framework (SEI Framework)
(c) USC-CSSE 7

• Introduction
– Overview
– Physical vs. Logical
– Who needs SLOC
– Existing SLOC definitions
• Problems With SLOC Counting Practice
– Limitations
– Tool Mismatch
• Counting Standard
– What to count
– How to count
– Example
• Conclusions
(c) USC-CSSE 8

• Focus on What to Count rather than
How Many to Count
– Provides a good checklist of the items that should be counted
– Does not have the standard of how many to count for each item
– Leave that decision to the user
• often leads to inconsistency in user’s choice
(c) USC-CSSE 9

• Example
– Two different companies may have two different results for the following:
How may logical
SLOC counted?
if (x > 0) { printf(“x is a positive number”);
} if (x > 0) printf(“x is a positive number”);
1 or 2 SLOC?
(c) USC-CSSE 10

• Counting tools
– At least 20 SLOC counting tools publicly available.
Few supports logical SLOC
– Logical SLOC results from tools are significantly different
• Experiment
– Three SLOC counting tools: CodeCount, RSM, and LocMetrics
– Counting physical and logical SLOC of three open-source software: OpenWbem, FlighGear, and wxWidgets
(c) USC-CSSE 11

• Comparison Results:
Product
(partial source code)
Physical CodeCount™ RSM LocMetrics
Logical Ratio Logical Ratio Logical Ratio
OpenWbem
FlightGear wxWidgets
14,000 7,100 1.97
4,700 2.98
6,600 2.12
14,000 10,800 1.30
7,600 1.84
9,900 1.41
50,300 30,700 1.64 21,300 2.36 27,300 1.84
(c) USC-CSSE 12

• Results (cont)
– CodeCount’s logical SLOC are about:
• 150% of RSM
• 110% of LocMetrics
– COCOMO Estimates
• RSM: 67% of CodeCount’s
• LocMetrics: 88% of
CodeCount’s
COCOMO Estimation - Nominal Ratings wxWidgets
140
120
100
80
60
40
20
0
127
CodeCount
85
RSM
Tools
112
LocMetrics
(c) USC-CSSE 13

• Need to have consistent counting standard to tell how many count for each item identified as item to count
• Standard would help to extend the applicability of SLOC metric for software measuring
(c) USC-CSSE 14

• Introduction
– Overview
– Physical vs. Logical
– Who needs SLOC
– Existing SLOC definitions
• Problems With SLOC Counting Practice
– Limitations
– Tool Mismatch
• Counting Standard
– What to count
– How to count
– Example
• Conclusions
(c) USC-CSSE 15

• We are proposing the a counting standard which we have used and tested in our USC CodeCount ™ research project over years
• Two components:
– What to count
– How many to count
(c) USC-CSSE 16

Checklist of What to Count
Measurement Unit
Source statement type
Executable
Nonexecutable
Declarations
Compiler directives
Comments
Blank lines
How produced
Programmed
Converted with automated translators
Copied or reused without change
Modified
(c) USC-CSSE 17

Checklist of What to Count
Measurement Unit
Origin
New work
Previous work: taken or adapted from
A previous version, build, or release
A reuse library (software designed for reuse)
Other software component or library
Usage
In or as part of the primary product
Delivery and Development status
Delivered as source
System tests completed
(c) USC-CSSE 18

Checklist of What to Count
Measurement Unit
Functionality
Operative (accessible, in-use code)
Functional (intentional dead code, reactivated for special purposes)
Replications
Master source statements (originals)
Physical replicates of master statements, stored in the master code
Language
Separate totals for each language
(c) USC-CSSE 19

• Hard to define the beginning and end of a statement
• Only executable and non-executable is not enough
• So, we identify and group different statement types such as selection, iteration, jump, and expression
(c) USC-CSSE 20

Measurement Unit
Executable lines
Statements
Non-executable lines
Declaration (Data) lines
Compiler directives
Order of
Precedence
Physical SLOC Logical SLOC
1
2
3
One per line Language-specific
One per line
One per line
One per declaration
One per directive
(c) USC-CSSE 21

Logical SLOC Counting Rules for C/C++, Java, and C#
Structure
Selection Statements: if, else if , else, “ ?
” operator, try , catch, switch
Iteration Statements: for, while, do..while
Order of
Precedenc e
1
2
Logical SLOC Rules
Count once per each occurrence.
Nested statements are counted in the similar fashion.
Count once per each occurrence.
Initialization, condition and increment within the “ for ” construct are not counted. i.e. for ( i= 0; i < 5; i++)…
In addition, any optional expressions within the “ for ” construct are not counted either, e.g. for (i = 0, j = 5; i < 5, j > 0; i++, j--)…
Braces {…} enclosed in iteration statements and semicolon that follows “ while ” in
“ do..while
” structure are not counted.
(c) USC-CSSE 22

Logical SLOC Counting Rules for C/C++, Java, and C#
Structure
Jump Statements:
Return, break, goto, exit, continue, throw
Expression Statements:
Function call, assignment, empty statement
Statements in General:
Statements ending by a semicolon
Order of
Precedence
3
4
5
Logical SLOC Rules
Count once per each occurrence.
Labels used with “ goto ” statements are not counted.
Count once per each occurrence.
Empty statements do not affect the logic of the program, and usually serve as placeholders or to consume CPU for timing purposes.
Count once per each occurrence.
Semicolons within “ for ” statement or as stated in the comment section for “ do..while
” statement are not counted.
(c) USC-CSSE 23

Logical SLOC Counting Rules for C/C++, Java, and C#
Structure
Block Delimiters, braces
Compiler Directive
Data Declaration
Order of
Precedenc e
6
7
8
Logical SLOC Rules
Count once per pair of braces {..} , except where a closing brace is followed by a semicolon, i.e. }; .
Braces used with selection and iteration statements are not counted. Function definition is counted once since it is followed by a set of braces.
Count once per each occurrence.
Count once per each occurrence.
Includes function prototypes, variable declarations, “ typedef” statements. Keywords like “ struct” , “ class ” do not count.
(c) USC-CSSE 24

Example if (x != 0) printf (“non-zero”);
SLOC
1
1 if (x > 0) printf (“positive”); else printf (“negative”);
2
1 for (i = 0; i < 10; i++)
{ printf (“%d”, i);
}
1
0
1
0 do { i = i - 1;
}while (i == 0);
(c) USC-CSSE
0
1
1
25

• Current SLOC counting practice has inconsistency problem
– Counting standard should focus on not only what but also on how many to count
– A standard and consistent SLOC definition is necessary
• Our proposed counting standard has applied in USC CodeCount ™
(c) USC-CSSE 26

Thank you!
(c) USC-CSSE 27