• Home
  • RSS Feed
  • Log in

Why not to initialize your local variables at declaration
Posted by Vincent Partington just before lunchtime: October 13th, 2006

In quite a few coding standards I have seen a guideline saying all local variables must be initialized at declaration. No doubt the authors were copying from, erm, inspired by Sun's Java coding standard guideline 6.2 which says

Try to initialize local variables where they're declared. The only reason not to initialize a variable where it's declared is if the initial value depends on some computation occurring first.

Sounds all nice and dandy. What could be wrong with that?

Well, the result of this guideline is that a lot of developers who can't think of a useful value to initialize their variable with decide to initialize it with null instead of leaving it unitialized. This has the nasty property of not catching a lot of NullPointerExceptions that would have resulted in a compile time error along the lines of "The local variable x may not have been initialized" if the developer had just left that variable uninitialized instead.

It's a pity Sun recommends such silly things which were probably inspired by the C/C++ era when uninitialized variables would contain garbage. Then again, Core J2EE Patterns is still in print while nearly all of the patterns described in it are either outdated or wholly inappropiate by now. But more on that later...

  • Share/Bookmark

Filed under Java | 3 Comments »



3 Responses to “Why not to initialize your local variables at declaration”



    erozendaal Says:
    Posted at: October 13, 2006 at 3:58 pm

    To me the sun standards recommend that the declaration of a local variable should be moved to where it is first assigned (initialized). This way the variable is _always_ initialized with a correct value.

    Only if this is not possible (for example, due to some computation that cannot be extracted into a separate method) would you declare a local variable without initializing. Like you said, assigning “null” or some other random value is a bad thing in this case since the compiler is no longer able to help you avoid errors.



    Vincent Partington Says:
    Posted at: October 13, 2006 at 4:34 pm

    Exactly. Instead of Try to initialize local variables where they\’re declared it should have said Try to declare local variables where they\’re initialized. Then the compiler could prevent a lot of these initialization problems instead of users getting an NPE at runtime.

    Regards, Vincent.



    Thor M Says:
    Posted at: December 22, 2007 at 11:24 pm

    Consider the following code I often see:

    void ...(...)
    {
       object o = null;
       object o = DoSomething(...);
       if (object != null)
       {
          ...
       }
    }
    

    It’s a stupid double assignment. The DoSomething method assigns to variable because it always returns a value or throws an exception.
    It’s a case where the compiler could easily outwit the *programmer*.



Leave a Reply

Click here to cancel reply.

Deployment automation for Java application running on Websphere, WebLogic and JBoss

Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India

Categories

  • Java (282)
  • Agile (109)
  • General (50)
  • Testing (42)
  • Performance (42)
  • Hibernate (36)
  • Scrum (33)
  • Podcast (31)
  • Architecture (31)
  • Spring (28)
  • SOA (24)
  • Maven (22)
  • Project Management (22)
  • Middleware (23)
    • Deployment (14)
  • Flex (17)
  • JPA (17)
  • Eclipse (15)
  • Xebia Labs (15)
  • Quality Assurance (14)

Tag Cloud

    SOA JavaOne Maven Agile Awareness Workshop Semantic Web Scrum Closures Groovy Scala Performance Architecture Introduction to Agile Java Testing XML Agile Poppendieck Functional Programming IntelliJ product owner Xebia Seam Grails fitnesse Hibernate Ajax qcon Spring esb Lean