Skip to main content

A thought on code metrices



We always face interesting discussion on code matrices. I got a funny but very interesting understanding of the types of metrices and its prioritization that we always talk about.  I would spread code metrics into two categories,

  •        Code matrices that can be identified with bare eyes by a developer.

  •       Code matrices that cannot be identified with bare eyes by a developer.

 Code matrices that can be identified with bare eyes are
  • Unused types
  •  Depth of inheritance
  • Code comments etc.

The above matrices can be identified by a developer while coding or refactoring and he can react on them immediately. For example, if he / she see an unused import he / she can delete it. He / she does not have to wait for a tool to detect it or to Google for a new tool to recognize this measure. Same applies for code comments, do not write comments if you find any irrelevant comment delete them right away.   

Code matrices that cannot be identified with bare eyes are
  •       Test coverage
  •        Cyclomatic complexity
  •        Package cycles
  •        Duplicates etc.

The above matrices can not be identified by a developers using his bare eyes. These are not easily detectable by the developer. These matrices are calculated based on some formulas or these are not a very straight forward calculations. Test coverage you cannot identify while coding you have to use some tools to identify that. Similarly cyclomatic complexity you may not be able to identify while coding or may not be interested to invest more time on that. So in these cases we need a tool to measure these matrices and maintain a standard count.

Hence matrices that really needs tools to recognize should be prioritized first and then others. Matrices like code comments, unused types can be of least priority as it is easily detectable and fixable.

Comments

Post a Comment

Popular posts from this blog

Spring: Method Injection

This is useful when a Singleton bean need to use a non-singleton bean. Sometime your application may need to collaborate a prototype bean with a singleton bean to satisfy your business logic. That is your singleton bean is dependent on a prototype bean. Let’s consider three beans Customer Sales Person Product A customer may ask a sales Person to show different type of products from the repository. Let’s assume you have gone to a garment shop to buy a new shirt for the lucky date with your new girlfriend. So, it’s a tough choice and you may like to try different colors and styles and finally you will choose one. So, if we describe the above situation in the form of business logic inside one of your module, it will look like this, The sales Person should show a new product every time he requests. Let’s assume Customer and Sales Person to be singleton bean in your Spring container and Product as prototype. But based on bean life-cycle a prototype bean can not be injec...
Post a Comment
Read more

Copying objects – Java Clonable interface

We can assign reference of an object to another, provided each of them satisfies an “ is-a” relationship or of same type. For example, a Dog object can hold the reference of another Dog object regardless both have different states. Similarly an Animal object can hold the reference of a Dog or Cat object, if they satisfies an “is-a” relationship. But hold on, these assignments do not help you to create a duplicate copy of the object. It’s nothing but different pointers pointing to the same memory location. Java provides API to clone an object. Using this API one can get a copy of an object to another. To achieve this, proposed class should implement Clonable interface (else JVM will throw CloneNotSupportedException during runtime). The rationale behind cloning is to get an independent copy of an object. The Object class has a clone() method which takes care of this operation. This method is protected by nature and returns an Object , when called.   You can call this ...
Post a Comment
Read more

JUnit Rule : Creating Temporary Folder

I was surprised to see this beautiful feature in JUnit and it helped to ease to lots of constrains I face while writing JUnit tests. I basically follow TDD and as you guys know we focus more on writing tests, hence it is necessary to use some shortcuts availed by the tools like JUnit to make the process fast. Recently I had an issue where I had to create and delete a file before and after every test executes. I did that using @Before and @After annotation of Junit and it worked, however I was looking for more of a generic way to do this at one place. As I started googling I came across this post, which is amazing,  After reading the block I know how I can generalize my creating and deleting of a temporary file or folder (I decided to go with a temporary folder and a file inside it, which looks more readable and oganized). The JUnit class: public class TemporaryFolderTestCase { @Rule public TemporaryFolder temporaryFolder = new TemporaryF...
Post a Comment
Read more