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 (5)

  1. mscherotter says:

    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

  2. rgr says:

    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

  3. brantgurga says:

    For C-based languages, the atomic unit is a statement in my opinion (which are usually one-per-line). For XML-based languages, the atomic unit is an element consisting of a beginning tag, content, and an ending tag with no great correlation to lines due to empty elements, attributes, and other things.

  4. albertito says:

    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!

  5. rgr says:

    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