counting lines of code

[shana07]

good day! I wanna check defect density of an open source tool. This tool can be used for creating a continuous build process. Most of the software is written in java, with a number of additional files written in html, css, html, javascript, xslt, jsp. This tool also has a web interface for users to view their work.

My questions are:
1. Are there possibilities of getting bugs in those additional files such as html, css etc?
2. Do I have to count lines of code of those files?

please feel free to give any comments. thank you.

[eWish]

When you say "Bugs" are you referring to rendering issues or issues that might hinder the way the tool you are testing works / functions?

I am not clear as to why you would need to count lines of code for HTML/CSS.

Would you please explain your questions better.

--Kevin

[shana07]

I was thinking that, bugs may contain in html/css files as well. Let us say that users report some issues/bugs, and in order to fix it, developers have to do changes to the java code and maybe to the javascript, html, css etc. That's why I was confused, do i have to count lines of code of the java files only or all files too? Don't you think so....

Which files should I take to count lines of code of an open source tool, let's say from the SourceForge.net (usually the distribution comes with xml config files, css files, etc). Thank you.

[eWish]

For more a general answer, I would say that if you know which line of code is causing issues then yes count the lines to get to the proper line to make the fix. If you only know that the HTML or CSS file is not rendering the way you expected, then I would not see where counting the lines of code would matter.

Moving to the Misc forum is this is not an HTML/CSS question, but rather more of a general question.

--Kevin

[shana07]

Alright. In this case, I was assuming developers have to change or add more lines to the html/css files too although not all the time.
Sorry, I'm unsure about the rendering thing that you have mentioned, in html and css, are they for visualization purposes only?

[eWish]

The HTML is the markup for the structure of the page. The CSS is for the presentation / visualization of the page. Rendering would be more of how the browser displays the page.

--Kevin

[shana07]

Got it..so what do you think the best either counting or not the lines of code of the html and css files of a java tool that provides a web interface, for measuring defect density. feel free to comment.

[shana07]

Sorry one more thing, how about 'build.xml' file in each distribution package of an open source tool? Do you think should be counted or not...

[Nepomuk]

As far as I know the build.xml is a file for a tool called ant, which builds the java project. So if you want to count the lines of code needed to create the project, yes, count those lines too.

On the other hand, counting the lines of a project isn't very informative really - for example the code snippets

public int add(int a, int b)
{
   int c;
   c = a;
   c += b;
   return c;
}

and

public int add(int a, int b) { return a+b; }

have pretty much the same functionality, but the line count is quite different. So you can do it of course, but it doesn't necessarily make sense. You'll have to decide for yourself.

Greetings,
Nepomuk

[shana07]

I agree. LOC is not very informative when there are different styles of coding

I was about not to count LOC of build.xml, because my task here is related to defect density, what do you think? can the build.xml contain bugs?

[Nepomuk]

I'm no expert on ant, but I'd guess that theoretically a build.xml can contain errors just as well as any other file. In most cases however such errors should be detected when building the project - I would think. So, better count it as well, if you continue counting.

Greetings,
Nepomuk

[shana07]

You're right - 'errors should be detected when building the project'. So when measuring on delivered defect density, I think build.xml should not be counted, as most of the time it will work.
Thanks for the useful replies, all.