Member Avatar for loctan

I am working towards my masters degree through an online university. As part of this I need to have a final project. I enjoy doing embedded work, but due to the lack of oscilloscopes, power supplies, machining tools to build a robot, I am looking towards doing another kind of application.

I was thinking it would be interesting to create an eclipse plugin that would collect various software metrics. This plugin would integrate seamlessly in the IDE and could collect various metrics about a software project/module/function such as:

1) SLOC
2) Level of cohesion
3) Amount of coupling between modules
4) Cyclomatic Complexity
5) Number of times a module/function is called to suggest good areas for optimization

Some of this information could even be displayed graphically or in list format. For instance, the cyclomatic complexity could on a per function basis such that a user could see which functions have the highest and this would imply that it may be necessary to simplify the code, etc. The amount of coupling between the various modules could also be displayed to show poor design, etc.

I guess my basic question is what you guys think of something like this? Can you offer any other interesting metrics to collect?

  • 6 Contributors
  • 6 Replies
  • 197 Views
  • 2 Weeks Discussion Span
  • Latest Post Latest Post by sujith.it

Dani AI

Generated

An Eclipse plugin that gathers both static and runtime signals makes for a solid masters project: it demonstrates program analysis, IDE integration, and usable visualization. ’s baseline ideas (size, cohesion, coupling, cyclomatic complexity, call counts) are good starting points; ’s revision‑density idea is especially useful as a change‑driven signal that often correlates with instability. Combining several orthogonal metrics reduces false positives and yields more actionable hotspots than any single number.

Useful additional metrics and signals to collect (beyond the thread’s suggestions):

  • Code churn / edits per day and age‑weighted revision frequency (implements ’s idea).
  • Clone detection (duplicate blocks) and duplication percentage per file.
  • Test coverage per class/module and failing tests from CI.
  • Static warnings density (compiler/linter findings per KLOC).
  • Maintainability index or Halstead volume as composite indicators.
  • Comment‑to‑code ratio and TODO/FIXME counts.
  • Fan‑in/fan‑out, public API surface, and dependency centrality.
  • Runtime hotspots (sampled call counts, allocations) collected optionally via instrumentation.

A practical, incremental implementation plan: start with an AST‑based static analyzer (Eclipse JDT for Java) as a background builder so metrics update on save; add a VCS adapter (JGit or command calls) to compute churn and revision rates; integrate coverage data from CI artifacts or local coverage tools; make runtime insights optional and sampled to avoid overhead. Persist metrics per commit or per timestamp so trend graphs are possible, and export as CSV/JSON for later analysis.

A compact example for cyclomatic complexity with an AST visitor:

int complexity(MethodDeclaration m) {
  AtomicInteger c = new AtomicInteger(1);
  m.accept(new ASTVisitor() {
    public boolean visit(IfStatement n){ c.incrementAndGet(); return true; }
    public boolean visit(ForStatement n){ c.incrementAndGet(); return true; }
    public boolean visit(WhileStatement n){ c.incrementAndGet(); return true; }
    public boolean visit(ConditionalExpression n){ c.incrementAndGet(); return true; }
  });
  return c.get();
}

Practical cautions: ignore generated code, cache results, run incremental analysis to avoid UI lag, and present metrics as guidance not absolute judgments (common heuristics flag cyclomatic >10 as “high,” but thresholds should be configurable). Integrating a few complementary metrics and exposing trends yields the best return for maintenance and refactoring decisions.

Recommended Answers

All 6 Replies

Member Avatar for jwenting

not interesting.
Just buy an osciloscope, they're cheap.

commented: :D +1
Member Avatar for iffEngineer

You know you wouldn't necessarily need an O-Scope to do something cool with embedded controls. For example, you could get six or seven servos and wire them into a digital circuit. Something simple like an AND > OR > XOR circuit. Then take the output of your gates and put them into a simple ribbon plug in. Now from your computer use the LPT1 port because you can use that port to send and receive digital signals. Now build or buy a simple robotic head or hand or something cool and wire the servos in to control it. Write a program using vb.net or C# utilizing .NET framework 2.0 and have a front end to control the robot. You could even use SAPI from microsoft to do some simple speech commands to control the robot. I am sure this is much more simple than what you need but you could follow that track if you still wanted to use embedded objects without the fancy frequency generators and O-Scopes.

Member Avatar for loctan

Thanks for you input guys. I have been and will continue to think about this. I actually have access to oscilloscopes and power supplies/function generators at work, but NASA can be a pain in letting people use them for non NASA related work.

I am going to see what I can work out and will continue to think about this and give it a proper reply in a few days.

Thanks again.

Member Avatar for Salem

> Can you offer any other interesting metrics to collect?
The total number of revisions (across all the branches) divided by the age of the file.

Use it to find files which are being edited rather more often than they should. This could indicate sloppy design, poor testing, vague requirements etc.

Member Avatar for Ken Sharpe

Good idea, Salem.

Member Avatar for sujith.it

Software matrix is a very important in competitive market. Specially if you plan to start your own business it will be your main asset.

____________
conservatory

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.