Digest of TIPS from Refactoring: Keeping the promise ;)

I'm very much infamous for breaking promises. I promise but glibly forget to keep it. Sometimes I'm paranoid with the thought that

Promise is made to break

But I'm dying to prove that I'm not bad in my "digital" life as in my "analog" life. Here, I promised to bring the TIPS of Refactoring from Martin Fowler's masterpiece "Refactoring". I'm going to keep that. Some of the words are ditto copy of the book.

Definition of Refactoring:
Refactoring has two definition depending upon the context.
Refactoring (noun):

a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor (verb):

to restructure software by applying a series of refactorings without changing its observable behavior.

Why do we need Refactoring?
All the points are self-explanatory. The details discussion available in the book.

• Refactoring Improves the Design of Software.
• Refactoring Makes Software Easier to Understand.
• Refactoring Helps us to Find Bugs.
• Refactoring Helps us to Program Faster.

When do we need Refactoring?

• When Add Function is to be added.
• When need of Fixing a Bug arise.
• When Code Review is to be done.

TIPS:

• When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
• Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking.
• Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug.
• Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

My thoughts:
Refactoring is a similar type of concept as Design patterns, but the purpose is different. As design pattern has it's catalog and vocabulary, Refactoring also has the same. But catalog of Refactoring is less known than that of design pattern; Refactoring concept came later then design pattern. Design patterns is handy during the design phase but Refactoring is useful during the maintenance phase. Refactoring prevents the decay of the software with time. Exhaustive discussion about Refactoring is available here: http://www.refactoring.com/

Going back to my former programming love:C, C++, but lazily

Well, I've grown up?, I've grown up in Java?? No dude, I've just one and half year professional experience in Java. Before that i.e. during my college days, mostly I programmed in C, C++ and sometimes in VC++ , I used Java, but that was not as much as C or C++. C and C++ was my programming love that time. I used to program in Turbo C++ compiler, also tried free C++ compilers like Dev C++ etc. For VC++, I used Microsoft VC++ compiler. I was quite happy with all these and C, C++ were my favorite languages. At that time I was not able to realize the real OOP philosophy although C++ is OOP language.
But I started my professional life with Java and eventually in almost no time I fallen in love with this beauty. Basically the my passion evolved from my profession. I write code now and refactor often for better code. All these I can do with Java now. Java is very much object-oriented. From my course of learning, I can feel the morbid necessity of OOA/D in any professional software now a days. And that is a one-to-one mapping for Java, that's why I love this language so much. Java encourages standard, prototype based, well defined design philosophy but does not force it.
But in my little experience I meet people(talented experienced as well as novice) who don't like Java that much. Even they frequently find drawbacks, lack of language features in Java. But I personally think

One who best know something only can criticize that thing.

So if I want to discuss anything deeply good or bad about C, C++, then I have to master these. I have to find out what's the real philosophy of the design of these language. It's true that not every programming language is suited for every purpose. Hence if your purpose is system programming, then Java may not be your choice, but if you program large scale enterprise solution backing large database or you write rich client software platform independently or any piece of software which runs long run under going design to maintainence phase, then Java may be the best solution.
I'm started to program in C, C++ again in my pastime. I started with Microsoft VC++ Express Edition. Here is my desktop with the IDE:

I think if somebody really want to develop language design concept and philosophy, then only one or two language knowledge is not enough for her/him. You have to explore other languages too. So If you want to open your mouth, then you have to know very well..

You can drive final Mustang now!!

Sun has released Mustang(Java 1.6) today.
Have a drive if you not tasted yet.