Recent changes to feature-requests

#11 Ignore folders that are not relevant for metrics calculation

Lance Walton — Tue, 25 Jun 2013 21:37:04 -0000

If you take a look at the help pages within Eclipse, you'll see a page called 'Exclusions'. That tells you how to do what you're asking, I think.

In case you can't find it, here's the relevant part:

If you have Java files for which you do not want to have metrics calculated, you can exclude them. To do this, open the project's Properties in any Java Perspective and select the 'Metrics' tab. You can either choose the files to ignore by browsing the file system -- press 'Add Files...' -- or you can enter a Perl5 regular expression that matches the file path -- press 'Add Regex...'.

Ignore folders that are not relevant for metrics calculation

Alexander Veit — Tue, 25 Jun 2013 21:08:11 -0000

Currently there seems to be no way to ignore certain folders, tests, samples, or sub-projects. This makes it difficult to restrict metrics calculation to production code.

Exclude resources at method level

Alex Oliveira — Thu, 30 Aug 2012 13:50:30 -0000

It would be really usefull to be able to exclude resources at the method level, not only at the file level.
The easiest example are the methods hashCode and equals. They are often generated automatically and we don't care about their cyclomatic complexity.

Suggested solutions (one or many of):
- Expand the tree in the Resource Selection window until the method level (like in the Package Explorer View)
- Use regular expressions to exclude methods (like .*#equals)
- Put a comment on each methods to be excluded
(Using annotations may not be a good idea, since many code target SDK's lower than 1.5)

Metrics feature control by comment or annotation

Anonymous — Mon, 23 Mar 2009 08:15:35 -0000

I often want to disable metrics feature for a only one function. If Metrics feature can be controlled by comment like @unused annotation, it is very convenient.

Feature envy and inner/anonymous classes

Anonymous — Thu, 12 Mar 2009 15:48:59 -0000

The "feature envy" counts can either take into account or not, thanks to a checkbox, access to one's superclass data.

I would like to see similar checkboxes for when an inner class or an anonymous class access data from its outer class.

The rationale is that most anonymous classes do nothing but use their outer class's data. They most often don't have fields of their own, and if they have more than one field they should probably not be anonymous. So I think the current "feature envy" warnings for anonymous class are misleading: this is actually good design.

For inner but non-anonymous classes, I'm not so sure -- but with a checkbox it should be easy enough to try both for a while and decide whether the warnings are justified or not.

Feature COCOMO metrics on project summary page

EndreStølsvik — Tue, 20 Jan 2009 13:27:43 -0000

"The COnstructive COst MOdel (COCOMO) is an algorithmic Software Cost Estimation Model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics."

Is has one major in-parameter: KLOC. In addition, it has a bunch of "tweaking parameters", adjusting the factors in the forumla. These are elements like the "development mode" and developers' experience etc.

" The basic COCOMO equations take the form
E=ab(KLOC)^bb
D=cb(E)^db
P=E/D
where E is the effort applied in person-months, D is the development time in chronological months, KLOC is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in the following table. ... "

http://en.wikipedia.org/wiki/COCOMO

Online calculators:
http://www.cms4site.ru/utility.php?utility=cocomoii
http://cost.jsc.nasa.gov/COCOMO.html
(Read note at top)

It would be cool to have some numbers calculated from this model in the project summary page. The numbers should be calculated for each of the "development mode", as this adjusts exponential factors that decide the outcome rather heavily.

"LOC" is unspecified. New "LOC". "TotalNOS".

EndreStølsvik — Tue, 20 Jan 2009 12:46:00 -0000

What the "TLOC" counts is not specified anywhere, at least that I have found.

Through testing, I've found the following to be true:
Everything about every method and constructor in all classes is counted:
--------
/**
* Javadoc
*/
public TestClass() {
// comment

super(2)
}
--------
The above method counts all lines (8).

Nothing else seems counted, even not field declarations, nor static initializers or instance initializers, nor the class declaration itself.

It seems like the "Total number of method Lines of Code", really.

Here's some suggestions:
*) "TLOC" should be renamed to "Total MLOC", and a definition of what it is should be clearly defined.

"TLOC" is ambigious - I've seen it defined as "Thousand LOCs" (some sites) and "Terra LOCs" (Wikipedia). The only I've seen defining the T as "Total" is Eclipse Metrics?

*) Possibly just drop the current "TLOC" altogether: I would _never_ have guessed the current specification of it: I feel it is rather counter-intuitive in many aspects. Or at least consider the above suggestion regarding name.

*) Another LOC-definition that include /all/ lines that are program code, but excludes /everything/ else (/all/ empty lines, comments, javadocs). Call it "Total LOC"? Include a small definition.

*) A LOSC that just counts _all lines_ in the source code (possibly dropping empty lines at the end of source files) - this to get an idea about the "girt" of the total source would it have been printed ("It would have required 7 x 500-pages packages of printer paper to print, given 125 lines per page). Call it "Total LOSC"? Include a small definition.

*) The total number of statements. Call it "Total NOS"? Include a small definition.

Metrics Since an Especific Date or User

m4rkuz — Mon, 03 Mar 2008 22:50:53 -0000

Hi,

The idea would be a configurable variable per project so you can retrive the metrics of a project from an especific date,

That's because sometimes you're not creating a project but adding classes and modifying others.
And some times you have a job project and get some very cool metrics for that with the pluging, but then you have another job project that requires modifying the same java project on you're eclipse and then you get mixe up metrics for the two projects.

It could be posible???

Exclude-Options for "Number of parameters"

dhiller — Wed, 18 Jul 2007 11:19:13 -0000

Although the metric "Number of parameters" is very valuable, in some cases you can't do anything against it:

Case 1: Override inherited method/Implement interface method:

If you create MyTreeCellRenderer extending DefaultTreeCellRenderer and override method "getTreeCellRendererComponent" you can't do anything against the method "getTreeCellRendererComponent" violating the rule "Number of parameters" except including it into the exclude list. This prohibits all other metrics from measuring the class, which IMO is not desirable.

Same is true for implementing interfaces (TreeCellRenderer).

Therefore I suggest introducing the option "Exclude overwritten methods/methods implementing interface".

Case 2: "Introduce parameter object" creates constructor violating above rule:

To avoid the above problem for your own methods you can use "Introduce parameter object" to shorten the parameter list. But as constructors are measured also you don't get out here.

For public constructors this may be a reasonable measure but for private ones, which I prefer to use for parameter objects, IMHO this doesn't make sense.

Therefore I suggest introducing the option "Exclude (invisible) constructors"

Request for Ant Task Support.

D. Ramakrishnan — Wed, 25 Apr 2007 05:07:11 -0000

It would be great to have an ant task that will take the location of java sources as input and a configuration file that will list all the metrics limits (or the metrics values could be given from within the ant task itself). This allows one to run the tool irrespective of the IDE used to develop the java sources. I want to have the same set of HTML reports along with the dashboard view that the tool generates.