Initializing Variables
in [Java Programming]
|
From: Alan Malloy on 26 May 2010 04:12 Jim Janney wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: > >> 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. > > You've lost me here. We all make mistakes, but I don't see how this > is supposed to help. Perhaps someone could post a short example? > void printList(MyLinkedList list) { MyNode n = null; // Some other initialization code // forgot to uncomment the next line // n = list.first(); while (n != null) { print(n); n = n.next(); } } Without the initial null assignment, the compiler will let you know you've made a mistake. Putting it there destroys the read-before-use checking and causes the method to do nothing at runtime, with no error detection at all. -- Cheers, Alan (San Jose, California, USA)
From: Tom Anderson on 26 May 2010 04:37 On Tue, 25 May 2010, Arne Vajh?j wrote: > 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. Absolutely. Goes without saying! tom -- Once you notice that something doesn't seem to have all the necessary parts to enable its functions, it is going to mildly bug you until you figure it out. -- John Rowland
From: Arved Sandstrom on 26 May 2010 05:25 Jim Janney wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: > >> On Tue, 25 May 2010, Patricia Shanahan wrote: >> [ SNIP ] >>> 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. > > You've lost me here. We all make mistakes, but I don't see how this > is supposed to help. Perhaps someone could post a short example? > Tom's observation follows from Patricia's comment about _routinely_ initializing at the point of declaration, Jim. And Patricia's comment refers to premature declarations (*). Without those qualifications then his observation would be quite absurd, I agree. :-) AHS * I don't use the word "premature" disparagingly. For reasons of clarity or scoping a local variable may be declared before a suitable value can be assigned.
From: Pitch on 26 May 2010 05:37 In article <Xns9D83A9201AC81noofflinecontactplea(a)94.75.214.39>, no.offline.contact.please(a)example.com says... > although non-local variables always get a default value anyway, > relying on that "is generally considered bad programming style". I explicitely declare a variable null only to show other programmers that I will explicitely check if it's null at some point. That means it's not an ordinary type field but a flag. So it's a matter of our in-house coding standard. -- stirr your cofee properly
From: Gunter Herrmann on 26 May 2010 11:28
Tom Anderson wrote: > On Tue, 25 May 2010, Arne Vajh?j wrote: >> 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. > > Absolutely. Goes without saying! There are exceptions to this rule (pun intended) Foo foo = null; try { foo = new Foo(); foo.doProcessing(); } catch (FooException ex) { doSomething(ex); } finally { foo.cleanup(); } In this case you have to initialize the variable foo. brgds Gunter in Orlando, Fla. |