item object in loop

[dar]

Hi all,

I'd like ask which possibility is better (safer, faster) to declare temporary object, when I go througth list (array, vector) and read each items of this list?
a) declare object outside of the loop
or
b) declare object inside the loop

What would you choose and why?
What about ResultSet? (java.sql.ResultSet)


Here is sample code.

a)

//item object is declareted outside of the loop 
Book item = null; 
    Iterator it = bookList.iterator();
while(it.hasNext()){
item = (Book) it.next();
item.cleanReaderList();
//....
//....
}  

b)

    Iterator it = bookList.iterator();
while(it.hasNext()){
                        //item object is declareted inside the loop
Book item = (Book) it.next();  
item.cleanReaderList();
//....
//....
}  
 

Thanks.

[pascal betz]

hi

my two cents:
declare variables as local as possible thus inside the loop. if you dont need it outside the loop, then there is no reason for it to exist outside the loop. this might give you a small performance pennalty, depends on the loop size.

cheers

pascal
[ July 13, 2004: Message edited by: pascal betz ]

[Vijayendra V Rao]

Well...I always prefer to declare all "Object" variables outside a loop. Which one is faster? Re-initialization or re-creation? Just think about it. If it was a basic Java-type then its not as heavy-weight a process. But I would never declare an object inside a loop.

[Vijayendra V Rao]

Sorry pascal...I didn't mean to step on your reply but I just wanted to highlight my opinion thats all.

[pascal betz]

vijay

how dare you
i just hope somebody is sharing my oppinion. otherwise i get this me-against-the-world feeling

cheers
pascal

[Stan James]

First, extra points for even asking! My standard rant follows ...

Code for humans first. They'll have a much harder time understanding your code than the compiler. Optimize for performance only after you have proven there is a problem.

For the humans, make your code express what you're trying to do. If a variable is used only inside the loop, make that explicit by declaring it inside the loop. If it's outside the loop a human might have to scan the rest of the method to see whether it was used before or after. Of course if the method is long enough that they have to look around for a variable we have other problems.

[Stefan Wagner]

I agree: more clean inside the loop.
And:
There should be some work left to the optimizer.

But there is a secret programmer-invention, made for this kind of problem. We gurus call it the for-loop:

     
for (Iterator it = bookList.iterator(), Book item = null; 
it.hasNext();
item = (Book) it.next())
{
item.cleanReaderList();
}

Intermediate programmers call this item the 'not-this-secret-much-too-long-and-hardly-readable-for-loop'-pattern.

To avoid this, trillions of hackers are wishfully waiting on java-1.5 aka 5.0, where it will be:

for (Book book : bookList)
{
book.cleanReaderList();
}

wishfully waiting too?

[Jeroen Wenting]

what's wrong with

for (Iterator it = bookList.iterator;
     it.hasNext();
     ((Book) it.next()).cleanReaderList());

Personally I don't like the 1.5 style loop syntax at all... Though autoboxing/unboxing and typed Collections could come in handy.

[Peter den Haan]

Originally posted by Vijayendra V Rao:
Well...I always prefer to declare all "Object" variables outside a loop. Which one is faster? [...]

The speed is exactly the same because both alternatives compile down to exactly the same bytecode. Try it. Use javap to disassemble the class files.

I really have to say that a preference for declaring variables outside the loop is misguided. And I believe that this is not simply a matter of style or opinion: if your goal is to maximise expressiveness and clarity, variables should have the smallest scope possible. Anything else is simply wrong (relative to this goal).

I guess I better explain this inflammatory tone Imagine you're picking up someone else's code, or for that matter, your own code after a while. You try to understand a given method, perhaps because you need to implement a change. You see

Book item = null;
for (Iterator it = bookList.iterator(); it.hasNext(); ) {
   item = (Book)it.next();
   ...
}

In order to understand the how this snippet works and what it does, you have to examine the entire remainder of the method. There might be some code elsewhere that picks up whatever Book the loop last iterated over. By making the scope of Book unnecessarily large, you have introduced additional potential complexity that you have to examine before you understand the method. Your intent is just to use the Book item within the loop. The code is a poor expression of this intent [1].

for (Iterator it = bookList.iterator(); it.hasNext(); ) {
   Book item = (Book)it.next();
   ...
}

This code is much easier to understand. It is obvious that any interactions with "item" are restricted to the loop itself; in trying to understand this bit of code, we don't need to look any further for potential other interactions.

Good code expresses the programmer's intent as clearly and concisely as possible.

Let me amplify this a bit more. Most of you are pretty bright and may think that this is a bit academic and exaggerated; after all, how hard is it to understand a simple loop? The answer is of course that it isn't. In a toy example like this, you won't even be aware of the difference in complexity. But in the real world there may be a dozen variables in a method. If all of them are essentially method-scoped, the number of possible interactions are huge, and consciously or unconsciously you have to understand which of those potential interactions are actually happening. The cumulative effect of all these little details is very significant indeed.

The same principle, by the way, applies to instance and class variables. If they're there just out of laziness because declaring and passing around local variables is too much work, that is deeply wrong. State is evil. A necessary evil, but still evil. Every bit of state makes interactions harder to understand. Do try to minimise the amount of (visible) state in any given scope.

- Peter

[1] The lack of expressiveness is made worse by the fact that the Book item is initialised to null. It should not be in this case. Looking at the code, the itent is that you should never get into a situation that you actually reference "item" before its assignment inside the loop. This intent is poorly expressed. Also, initalising it will prevent the compiler from checking that this variable is assigned to before use irrespective of the code path taken (conditionals, exceptions, etc).
[ July 13, 2004: Message edited by: Peter den Haan ]