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)
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.
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
Joined: Jul 04, 2004
Sorry pascal...I didn't mean to step on your reply but I just wanted to highlight my opinion thats all.
Joined: Jun 19, 2001
how dare you i just hope somebody is sharing my oppinion. otherwise i get this me-against-the-world feeling
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
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 .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.
 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 ]