If you were registered and logged in, you could join this project.
JMT: A tool for measuring and judging Java code
Welcome to the homepage of JMT, the Java-Measurement-Tool. JMT allows
you to measure and judge Java code. The methods used for measuring
and the rules used to judge the results are fully
customizable. Custom measurement-method can also be 'plugged in'.
A screenshot of the JMT application
Why Java code should be measured
Most of today's projects are developed by more then one single person.
And mostly the people who started the developing
are not the people maintaining and extending the project.
So today it is even more critical to think about the structure and
the design of code.
Is it simple enough? Is there anything we can do to ease maintaining?
Is it easy to understand and to learn?
Of cause judging code is highly subjectiv and depends on the
background and the intentions of the 'judges'.
But there are some areas where a measurement-program like JMT becomes a
These areas include:
- The method and attribute structure of the packages.
- The coupling between the classes and interfaces.
- The visible elements of a package, class or interface.
- The amount of lines of code used for implementation.
- The access modifier structur of a package.
- The number of attributes and their accessor methods.
Of cause this list is not complete. Even today we find new
interresting aspects about code measuring.
Does measuring change the way I program?
Well to be honest I do not know. My programming style changed because of
JMT. Well there are still some design questions left but now I am using
more advanced structures and pattern. I also know some of the basic weak
points of code that unnessesarly consume manpower and money spent on
Today I am using more interfaces, hide all public classes,
which are not designed to be public abstract and use static factories
to create objects rather then constructors. And well - I hate public constants.
I also started to use the construction pattern (sometimes referred as composing
pattern) in a better way while adapting some thoughts from psychology.
While developing JMT I done a redesign of the code to reflect my
increased knowledge and my changed emotional expectations. I introduced new
types (interfaces describing objects), hide all implementational aspects
and added public factories to create instances of the types. So I
eased the public structure dramatically and also reduced the overall lines
of code. After I switched to
factory creation instead of constructor creation, the constructors
became much simplier and the factories now mostly implement the flyweight
pattern which is mainly the root of siginificantly reduced memory usage and
also reduced execution time.
And that was caused by a bunch of numbers and some bad marks.
Weird, isn't it?