What does "Lines of Code" mean for a XAML file?

I have a utility that measures lines of code (CLC.EXE).  It works with C, C++, C#, Perl, x86 assembly language, command files and make files.   Now that I'm developing XAML code, I need to teach CLC how to measure XAML.  However, XAML is XML and isn't arranged in lines to the same degree as the other languages.

But, I need comparative statistics so I can compare and track the "size" of my XAML code.   So the question is, what are the meaningful metrics for XAML?   I don't think that "lines of code" is really that meaningful or usefully a metric for XAML.  You may argue that its not meaningful for the other languages either and I would agree with you to a point, but that's a conversation for another day...

How would you suggest I measure the size of a XAML file? Here are a few nascent thoughts...

• Simple lines doesn't make sense... but without a count of lines, it makes it hard to compare the 'size' of a XAML file to the 'size' of a C# file.
• What about the number of tags?
  • But some tags are simple, and some tags are complex
• What about attributes?  They are as important, or even more so, than the tags!
• Is nesting depth an important metric?

How about this is as a starting place: One 'line' of XAML is equivalent to one tag or one element.  That would make the following tag 22 lines of code in size.  Its not 23 becuase the terminating </ListBox> is part of the <ListBox> tag, not a separate tag.

   1:     <ListBox Margin="32,152,32,21" x:Name="RecentFilesLB"

    2:               Background="{x:Null}" BorderBrush="{x:Null}" 

    3:               IsSynchronizedWithCurrentItem="True" FontSize="18"

    4:               SelectionMode="Single" 

    5:               KeyUp="RecentFilesLBKeyUp" 

    6:               MouseDoubleClick="RecentFilesDoubleClick" 

    7:               FontFamily="Consolas" LostFocus="RecentFilesLBLostFocus">

    8:               

    9:        <ListBoxItem>Item 1</ListBoxItem>

   10:        <ListBoxItem>Item 2</ListBoxItem>

   11:        <ListBoxItem>Item 3</ListBoxItem>

   12:        <ListBoxItem>Item 4</ListBoxItem>

   13:        <ListBoxItem>Item 5</ListBoxItem>

   14:        <ListBoxItem>Item 6</ListBoxItem>

   15:        <ListBoxItem>Item 7</ListBoxItem>

   16:        <ListBoxItem>Item 8</ListBoxItem>

   17:        <ListBoxItem>Item 9</ListBoxItem>

   18:        <ListBoxItem>Item 10</ListBoxItem>

   19:   

   20:      </ListBox>

What are your thoughts?

Thanks!

Comments

• Anonymous
  December 30, 2006
  What is the end that you are trying to accomplish with the numbers?  Are you using it to justify a raise or impress your team?  Or is for your own "productivity"? I would use Number of Elements + Number of Attributes.   Michael

• Anonymous
  December 30, 2006
  Hi Michael :) Yes, I think number of elements and number of attirbutes might work well. I'm a bit curious about your comment?  I take it that you ascribe some less than forthright motives to my queston? Having usefull metrics about code is important.  Lines of code is a simple one.  Of course it shouldn't be the only one, or even the most important one.  But it is commonly used in our industry. Wikipedia has a nice article here: http://en.wikipedia.org/wiki/KLOC Regarding job performance, to my knowledge (and on the team I manage) KLOC isn't used as a measure of developer productivy at Microsoft.  Nobody that I know of ever got a raise or promotion, or was penalized based on such a simple measure. I generaly use KLOC to measure things like code churn (along with other measures), and gain some understanding of the size of a code base. Best Regards RGR

• Anonymous
  December 30, 2006
  The comment has been removed

• Anonymous
  December 30, 2006
  hi, I would try to count the number of entities because the interpreter must read them to parse the file, as if it was a XML Schema. bye!

• Anonymous
  December 31, 2006
  Hi Albertito :) I'll take a look at that - it might be a good approach - e.g. the number of XML entities may be generaly comparable to the number of tokens in a more traditional language. Thanks for the suggestion! RGR