Saturday, September 26, 2009

Comments, Imports and Constructors

According to the butterfly effect, even the slightest and minutest events can change the course of events in future. Hence, each change is significant for shaping the future.

Progress of a society can be calculated by the amount of change happening in that society. A transforming society appreciates and experiments with new ideas. But, if the new idea is evaluated using the framework of old ideas, then the old ideas become more and more rigid.

I learnt three new things which conflicted with my existing understanding. In the below points I do not want to coin the term old approach and new approach, since they are just two ways of approaching a concept.

The best way to appreciate a new idea is to experiment and see whether it makes sense.

1. Writing Comments in Code

What I Knew : Write as much comments as possible in your programs. The more the better. It can never be more than needed. I heard about various code-comment ratio - 1:1, 1:5, 5:1.

What I learnt *: Do not write a comment unless you feel that you failed to express your indent in your code. Means, write comments if your code is not expressive enough. If you have a public method

"public int findTotal(int amount1, int amount2)",

you can provide a comment "Finds the total of amount1 and amount2". This comment is redundant. Anything redundant in your code can be avoided. The method and argument names convey the indent of the programmer. Redundant content in your classes will make it difficult and time consuming to understand.

2. Wildcard imports (import*)

What I Knew : Never use wild card imports. Wild cards do not cause performance issues in java. Still the use of wild cards were considered as ineffective coding practise. The specific imports helps to identify the dependencies of your class.

What I learnt* : Use wild card imports. You just need to know which packages your class depends on. All the specific imports clutter your classes with too much information. Incase you need to know the specific imports at any point of time, you can see those imports quickly using the advanced features of the latest editors. In Eclipse, just go for 'Ctrl+Shift+O' to add specific imports.

Another reason is that specific dependencies are hard dependencies. Wild card imports reduces the coupling by avoiding the hard dependencies.

3. Default Constructors

What I knew : Always create default 'no-arg' constructors in your class, even if you do not need it at the moment. Tomorrow, if you may need to sub-class your parent class without a default constructor, you may end up in agony. If your sub-class needs a 'no-arg' constructor, you may have to write a 'no-arg' constructor for the parent class at that time.

What I learnt : Do not use default 'no-arg' constructers unless you require it.

What if my sub-class needs it tomorrow?

If your parent class doesn't indent to provide a 'no-arg' constructor, then its a design decision. Your sub-class is supposed to use only the constructor which is provided by the parent class.


* Courtesy - Clean Code by Robert C Martin


  1. RE #2 -- please read my article "Import on Demand is Evil" -

    The gist is that import-on-demand can cause previously-compiling code to stop compiling if code is added to other packages.

    For example, the following code compiles fine through Java 1.1.x:

    import java.util.*;
    import java.awt.*


    List list;

    When they added java.util.List in Java 1.2, the above code will no longer compile.

    Languages should not have features that allow your code to break if someone *adds* code to a library you depend upon...

  2. With Eclipse, Cmd/Ctrl-Shift-M/O and code folding, I sometimes forget if it's "import" or "include" in Java ;-)

  3. Nice write-up. My takeaway from #3 is if you're concerned about subclasses and constructors, change your design pattern from inheritance to something else.