Java Concept : No need to initialize boolean at class level

This concept says, boolean take the default value and does not required any pre-assignment if at class level
How ever if it is a local variable ie defined inside the method then compilation error for uninitialized variable might occur.

boolean

If we do like :

boolean var = false;

Then it reassign the same value in 2 steps and make is much more slower.

1. Assign default value (false) to variable. 

2. Assign user defined value to variable.

For better performance and clean code leave assignment to JVM Smile

What is 3Q’s Method of Code Refactoring

THE FIRST Q: QUICK WINS

The first stage is to catch low hanging fruits, like identifying and removing dead code, removing duplicate code, and reduce method length. At this stage the following measures would be helpful:

  • Cyclomatic complexity: should be 10 or below
  • Average method length: 15 or below
  • Code duplication for 3 (or greater) lines of code
  • Overall code size: should be monitored and set targets for reducing it

THE SECOND Q: DIVIDE & CONQUER

The next stage is to start thinking of pulling apart components, whether business (or functional) components or utility components. This re-organization of code is essential to break the complexity of code and will open a large list of refactoring opportunities. At this stage, we will add the following two measures:

  • Instability: to measure correct use of design layers
  • Efferent and afferent coupling between component interfaces and the outer world

THE THIRD Q: BUILD QUALITY IN

The last stage is to start writing unit tests to test component interfaces. This is necessary so that to baseline the code quality and start doing more profound refactorings. At this stage, we will add the following measure:

  • Unit tests code coverage

What is Code Refactoring ?

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

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility. Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program’s source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements.

I’ve been asked, “Is refactoring just cleaning up code?” In a way the answer is yes, but I think refactoring goes further because it provides a technique for cleaning up code in a more efficient and controlled manner. Since I’ve been using refactoring, I’ve noticed that I clean code far more effectively than I did before. This is because I know which refactorings to use, I know how to use them in a manner that minimizes bugs, and I test at every possible opportunity.

Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure. However, the purpose is different. Performance optimization often makes code harder to understand, but you need to do it to get the performance you need. Most of the the time refactoring improves performance in terms of speed as well, however at times its inverse could happen ie by extracting too many classes and introducing too many variable could have an impact of performance as well.

I want to reiterate that refactoring does not change the observable behavior of the software. The software still carries out the same function that it did before.

One thing at a time with TWO HATS ( Refactoring Vs Adding feature )

When you add function, you shouldn’t be changing existing code; you are just adding new capabilities. You can measure your progress by adding tests and getting the tests to work. When you refactor, you make a point of not adding function; you only restructure the code. You don’t add any tests (unless you find a case you missed earlier); you only restructure the code. You don’t add any tests (unless you find a case you missed earlier); you only change tests when you absolutely need to in order to cope with a change in an interface.

As you develop software, you probably find yourself swapping hats frequently. You start by trying to add a new function, and you realize this would be much easier if the code were structured differently. So you swap hats and refactor for a while. Once the code is better structured, you swap hats and add the new function. Once you get the new function working, you realize you coded it in a way that’s awkward to understand, so you swap hats again and refactor. All this might take only ten minutes, but during this time you should always be aware of which hat you’re wearing.

NOTE :

Please note that testing the while refactoring is very import. Always make small changes, test them commit them and make other changes. Do not thing to make all changes in a singe go and later on test entire application at the end. Multiple small cycles of refactor– test – refactor –test and smile Smile  is better then big refactoring – final testing – crying Sad smile

Best Practices – Keep Reading Existing Software Source Code

Best Practice 1- Keep Reading Existing Software Source Code

Let me ask you few basic questions before we start with one of the most important best practices required for a software developer.

  • Do you read movie magazines?

  • Do you read news papers?

  • Do you read road side advertisements?

  • Do you read junk written here and there?

  • Do you just read….?

Definitely your answer will be positive but if I ask you one more question in the series:

Do you read Software Source Code?

Only very few software developer will have positive answer because reading and understanding an existing software source code is the most boring task. If you are one of them who feel reading software source code is a boring task then you are missing one of the most important best practices, which a software developer should have in his/her life.

If you want to become a novelist, can you just start writing novels? I would say 100% no!!, you definitely need to read hundreds of novel before you start writing GOOD novels. If you want to become a movie script writer, can you start writing good movie script until you have gone through various good movies scripts?, again my answer would be no!!

So, if you want to write a good software code then how it will be possible for you to write good source code without reading tons of source code? Even if you will write something then how would you compare if what you write that is the best?

By reading others source code gives you opportunity to criticize the mistakes done in writing source code. You will be able to identify what are the mistakes other software developers have done in their source code which you should not repeat while writing good code.

There are many attributes of software codes ( indentation, comments, history header, function structure etc.), which you will learn by reading existing code specially, a code written by well experienced software developers. Spend some time in reading others source code and I’m sure you would be able to write BEAUTIFUL source code in few days or few weeks and you be able to fix the mistakes which you were doing so far in writing the source code.

One thing to experiment, just go in past and check the code you had written few years ago, you will definitely laugh….because you are always improving by doing practice.