jQuery in Action, 3rd edition
The moose likes Java in General and the fly likes item object in loop Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "item object in loop" Watch "item object in loop" New topic

item object in loop

Ranch Hand

Joined: Nov 08, 2001
Posts: 45
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
b) declare object inside the loop

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

Here is sample code.



pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547

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.


[ July 13, 2004: Message edited by: pascal betz ]
Vijayendra V Rao
Ranch Hand

Joined: Jul 04, 2004
Posts: 195
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 <br /> <br />"The harder you train in peace, the lesser you bleed in war"
Vijayendra V Rao
Ranch Hand

Joined: Jul 04, 2004
Posts: 195
Sorry pascal...I didn't mean to step on your reply but I just wanted to highlight my opinion thats all.
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547

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

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

I agree: more clean inside the loop.
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:

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:

wishfully waiting too?

Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
what's wrong with

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
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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 seeIn 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].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 ]
I agree. Here's the link: http://aspose.com/file-tools
subject: item object in loop
It's not a secret anymore!