Initializing Variables
in [Java Programming]
|
From: Patricia Shanahan on 25 May 2010 19:05 Rhino wrote: > I've received some criticism recently with regards to the approach I use to > initializing variables so I'd like to throw this issue out to the whole > group so that I can learn more about the pros and cons of the approach I am > using.... > > Basically, I initialize pretty much every variable as I declare it, just to > be sure it has some kind of value right away. That initial value is > typically a zero for a number or a null for an object. Some recent > criticism questioned this practice so I thought I'd review some of the > material that helped get me in that habit in the first place. .... I follow the extreme opposite view. I initialize a local variable at the point of declaration if doing so makes logical sense or I know that I know something the compiler does not know. Generally, that involves the compiler assuming a fall-through from a call to System.exit. The reason for doing this is simple. I make mistakes. I have done most of my work in environments in which pair programming is not feasible, so I cannot depend on another programmer to catch my mistakes. To the maximum extent possible, I want to co-opt Eclipse's continuous source code checking as an aid to finding my mistakes as quickly as possible. One mistake I might make is omitting a logically necessary assignment to a local variable. Routinely initializing at the point of declaration would eliminate the possibility that it might be detected by the compiler. When I get a definite assignment error I take the time to look at my logic. Just occasionally, simply adding an initializer to the declaration would leave either an actual error or unnecessarily convoluted code, and I do something else. This particular case only accounts for a few mistake detections, but is part of an overall strategy that works for me. Patricia
From: Lew on 25 May 2010 19:17 Arne Vajhøj wrote: > I strongly favor readability here. The extra overhead of something > getting initialized twice should be minimal or zero if the JIT > compiler optimizes it away. Minimal, perhaps, but the system is not permitted to optimize away member initialization. -- Lew
From: Lew on 25 May 2010 19:26 Daniel Pitts wrote: > So in general, I think initializing with a value you never expect to get > used is an error. If possible, instead of initializing, you should try > to find a way to cause a compiler error. Using final and local variables > are good for this. If you expect it to be used before it is > re-initialized, find a sensible default value. If you can't do either, > then at the very least document that fact very well, and throw > informative runtime errors if the value isn't initialized properly. > > Also, if you have a complicated code-path necessary for determining the > initial value, try moving that into a private method which returns the > value. That can make it simpler to understand. The thing I find objectionable is the pattern Foo foo = null; foo = actualInitialValue(); instead of Foo foo = actualInitialValue(); Initializing a member variable to 'null' is all right, albeit mildly unnecessary, if there's a chance its value will remain 'null', but I also expect every Java programmer collecting pay for the knowledge to understand that member values are already initialized to 'null' absent that explicit initialization. I expect anyone at least "intermediate" in Java to know that explicitly initializing a member variable to 'null' causes the variable to be assigned that value twice. If they accept that small overhead, fine, but they should know of it. Using 'final' and local variables (or both at once, 'final' local variables) is always good when possible because the compiler tells you if you got it wrong. The JLS has sections on "definitely assigned" and "definitely unassigned" that are worth study. -- Lew
From: Tom Anderson on 25 May 2010 20:22 On Tue, 25 May 2010, Patricia Shanahan wrote: > Rhino wrote: >> I've received some criticism recently with regards to the approach I use to >> initializing variables so I'd like to throw this issue out to the whole >> group so that I can learn more about the pros and cons of the approach I am >> using.... >> >> Basically, I initialize pretty much every variable as I declare it, just to >> be sure it has some kind of value right away. That initial value is >> typically a zero for a number or a null for an object. Some recent >> criticism questioned this practice so I thought I'd review some of the >> material that helped get me in that habit in the first place. > ... > > I follow the extreme opposite view. I initialize a local variable at the > point of declaration if doing so makes logical sense or I know that I > know something the compiler does not know. Generally, that involves the > compiler assuming a fall-through from a call to System.exit. > > The reason for doing this is simple. I make mistakes. I have done most > of my work in environments in which pair programming is not feasible, so > I cannot depend on another programmer to catch my mistakes. To the > maximum extent possible, I want to co-opt Eclipse's continuous source > code checking as an aid to finding my mistakes as quickly as possible. > > One mistake I might make is omitting a logically necessary assignment to > a local variable. Routinely initializing at the point of declaration > would eliminate the possibility that it might be detected by the compiler. > > When I get a definite assignment error I take the time to look at my > logic. Just occasionally, simply adding an initializer to the > declaration would leave either an actual error or unnecessarily > convoluted code, and I do something else. This is exactly what i do. By initialising locals at the point of definition, you immediately throw away the compiler's ability to sanity-check your assignments to them. Don't do that. tom -- Postmodernism's refusal of master narratives is a neat dodge, but doesn't get it out of the problem that it offers a master narrative. A teapot with 'this is not a teapot' stencilled on the side will still hold your PG Tips. -- G'
From: Arne Vajhøj on 25 May 2010 20:30
On 25-05-2010 20:22, Tom Anderson wrote: > On Tue, 25 May 2010, Patricia Shanahan wrote: > >> Rhino wrote: >>> I've received some criticism recently with regards to the approach I >>> use to initializing variables so I'd like to throw this issue out to >>> the whole group so that I can learn more about the pros and cons of >>> the approach I am using.... >>> >>> Basically, I initialize pretty much every variable as I declare it, >>> just to be sure it has some kind of value right away. That initial >>> value is typically a zero for a number or a null for an object. Some >>> recent criticism questioned this practice so I thought I'd review >>> some of the material that helped get me in that habit in the first >>> place. >> ... >> >> I follow the extreme opposite view. I initialize a local variable at the >> point of declaration if doing so makes logical sense or I know that I >> know something the compiler does not know. Generally, that involves the >> compiler assuming a fall-through from a call to System.exit. >> >> The reason for doing this is simple. I make mistakes. I have done most >> of my work in environments in which pair programming is not feasible, so >> I cannot depend on another programmer to catch my mistakes. To the >> maximum extent possible, I want to co-opt Eclipse's continuous source >> code checking as an aid to finding my mistakes as quickly as possible. >> >> One mistake I might make is omitting a logically necessary assignment to >> a local variable. Routinely initializing at the point of declaration >> would eliminate the possibility that it might be detected by the >> compiler. >> >> When I get a definite assignment error I take the time to look at my >> logic. Just occasionally, simply adding an initializer to the >> declaration would leave either an actual error or unnecessarily >> convoluted code, and I do something else. > > This is exactly what i do. By initialising locals at the point of > definition, you immediately throw away the compiler's ability to > sanity-check your assignments to them. Don't do that. That is a good argument. But I would note that in many cases the optimal solution is to wait declaring the variable until you have a value to give it. Arne |